From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27393 invoked by alias); 1 Feb 2010 01:25:49 -0000 Received: (qmail 27385 invoked by uid 22791); 1 Feb 2010 01:25:48 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Feb 2010 01:25:44 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o111P1Vs018599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 31 Jan 2010 20:25:01 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o111OwNM019234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jan 2010 20:25:00 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o111OwdP008107; Mon, 1 Feb 2010 02:24:58 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o111OwFQ008102; Mon, 1 Feb 2010 02:24:58 +0100 Date: Mon, 01 Feb 2010 01:25:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFC/ia64] memory error when reading wrong core file Message-ID: <20100201012458.GB6015@host0.dyn.jankratochvil.net> References: <20100129160222.GL26811@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100129160222.GL26811@adacore.com> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00001.txt.bz2 Hi Joel, this specific problem gets also fixed by: [patch] Sanity check PIE displacement (like the PIC one) http://sourceware.org/ml/gdb-patches/2010-02/msg00000.html which produces (gdb) core core warning: core file may not match specified executable file. [New Thread 5437] warning: PIE (Position Independent Executable) displacement 0xffffffffffffe580 is not aligned to the minimal page size 0x4000 for "/root/wrong-core-for-exe/call_crash" (wrong executable or version mismatch?) Reading symbols from /lib/ld-linux-ia64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux-ia64.so.2 warning: PIE (Position Independent Executable) displacement 0xffffffffffffe580 is not aligned to the minimal page size 0x4000 for "/root/wrong-core-for-exe/call_crash" (wrong executable or version mismatch?) Core was generated by `./crash'. Program terminated with signal 6, Aborted. #0 0xa000000000010640 in __kernel_syscall_via_break () Still I think you have found a problem of its own which should be fixed anyway. On Fri, 29 Jan 2010 17:02:22 +0100, Joel Brobecker wrote: > This explains the change of behavior, which is not entirely unreasonable. > That being said, I think that the new behavior is less useful for the user. I think the PASS->FAIL turn is in fact just accident, it could even turn FAIL->PASS etc. > What I suggest, is to catch all errors while trying to read the shared > library map, and try to continue without. Something like the attached? > > It gives me the following output: > > (gdb) core core > warning: exec file is newer than core file. > [New Thread 5437] > warning: Can't read pathname for load map: Input/output error. > Reading symbols from /lib/tls/libc.so.6.1...(no debugging symbols found)...done. > Loaded symbols for /lib/tls/libc.so.6.1 > Reading symbols from /lib/ld-linux-ia64.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib/ld-linux-ia64.so.2 > Core was generated by `./crash'. > Program terminated with signal 6, Aborted. > #0 0xa000000000010640 in __kernel_syscall_via_break () When some memory access fails it should be IMO printed as it is some sort of incorrect operation. Therefore I would prefer the attached patch producing: (gdb) core core warning: core file may not match specified executable file. [New Thread 5437] Cannot access memory at address 0x1000000000009 Cannot access memory at address 0x1000000000009 Cannot access memory at address 0x1000000000009 Reading symbols from /lib/tls/libc.so.6.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6.1 Reading symbols from /lib/ld-linux-ia64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux-ia64.so.2 Cannot access memory at address 0x1000000000009 Core was generated by `./crash'. Program terminated with signal 6, Aborted. #0 0xa000000000010640 in __kernel_syscall_via_break () (this dump has been made up a bit) > As mentioned on IRC, I could not test this on ia64-linux with the official > testsuite, as the testsuite run immediately crashes the two machines on > which I tried (after which I was firmly prohibited from making any additional > attempt on any other machines). Tested your original patch on RHEL-5.4 ia64 with no regressions using: make check-single RUNTESTFLAGS="--ignore 'watch-vfork.exp interrupt.exp'" Tested the patch attached below on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu (as it is IMO fully arch-independent). Technical details: This patch could be made more simple just by extending your patch by: print_any_exception (gdb_stderr, errstring, exception); Just if there exists catch_errors shouldn't it be used instead of TRY_CATCH? Moreover catch_errors is considered deprecated in favor of catch_exceptions. But I am open for inlining catch_errors there as you did, with that new print_any_exception call, if you agree. Moreover this patch is not required if a new patch for PAGESIZE sanity checking PIE displacement Thanks, Jan 2010-02-01 Jan Kratochvil Joel Brobecker * solib-svr4.c (struct solib_svr4_r_map_args): New. (solib_svr4_r_map): Call solib_svr4_r_map_stub and move the former code content to ... (solib_svr4_r_map_stub): ... a new function. --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -823,6 +823,30 @@ locate_base (struct svr4_info *info) return info->debug_base; } +/* Arguments for catch_exceptions's call of solib_svr4_r_map_stub. */ + +struct solib_svr4_r_map_args + { + struct svr4_info *info; + CORE_ADDR retval; + }; + +/* Stub interface for catch_exceptions's called from solib_svr4_r_map. */ + +static int +solib_svr4_r_map_stub (struct ui_out *ui_out, void *args1) +{ + struct solib_svr4_r_map_args *args = args1; + struct svr4_info *info = args->info; + struct link_map_offsets *lmo = svr4_fetch_link_map_offsets (); + struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr; + + args->retval = read_memory_typed_address ((info->debug_base + + lmo->r_map_offset), + ptr_type); + return 1; +} + /* Find the first element in the inferior's dynamic link map, and return its address in the inferior. @@ -833,11 +857,16 @@ locate_base (struct svr4_info *info) static CORE_ADDR solib_svr4_r_map (struct svr4_info *info) { - struct link_map_offsets *lmo = svr4_fetch_link_map_offsets (); - struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr; + struct solib_svr4_r_map_args args; - return read_memory_typed_address (info->debug_base + lmo->r_map_offset, - ptr_type); + args.info = info; + + /* Return 0 as a failure result if there is a memory read error. */ + args.retval = 0; + + catch_exceptions (uiout, solib_svr4_r_map_stub, &args, RETURN_MASK_ERROR); + + return args.retval; } /* Find r_brk from the inferior's debug base. */