From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64217 invoked by alias); 31 Mar 2015 23:39:39 -0000 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 Received: (qmail 64201 invoked by uid 89); 31 Mar 2015 23:39:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 31 Mar 2015 23:39:38 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2VNdaZg028781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 31 Mar 2015 19:39:36 -0400 Received: from localhost (unused-10-15-17-126.yyz.redhat.com [10.15.17.126]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2VNdap1012404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO); Tue, 31 Mar 2015 19:39:36 -0400 From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches Subject: Re: [PATCH] Catch exception on solib_svr4_r_ldsomap References: <871tke2b6a.fsf@redhat.com> <55152B9F.4090606@redhat.com> <87k2y2qdbu.fsf_-_@redhat.com> <551A8546.4000208@redhat.com> X-URL: http://blog.sergiodj.net Date: Tue, 31 Mar 2015 23:39:00 -0000 In-Reply-To: <551A8546.4000208@redhat.com> (Pedro Alves's message of "Tue, 31 Mar 2015 12:30:14 +0100") Message-ID: <878uecvirs.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01074.txt.bz2 On Tuesday, March 31 2015, Pedro Alves wrote: >>> So, gdb itself errors and stops processing the core? >> >> No, GDB does not "error and stop", but some testcases do that. > > Well, it clearly does do that. Hence your new patch. :-) > >>> I think I don't understand. :-) Can you please show an >>> example session? Did GDB continue processing the core when >>> it printed that error, or was it just a warning and it continued? >> > > I meant "Did GDB stop processing the core", of course. Sorry I misunderstood your question. >> Sure, sorry for not sending the example session before! Here is the >> pertinent part: >> >> (gdb) core /home/sergio/work/src/git/binutils-gdb/rhbz1085906-coredump-filter/build-64-3/gdb/testsuite/gdb.base/non-private-anon.gcore >> [New LWP 28468] >> Cannot access memory at address 0x355fc21148 >> Cannot access memory at address 0x355fc21140 >> (gdb) FAIL: gdb.base/coredump-filter.exp: loading and testing corefile for non-Private-Anonymous: load core >> FAIL: gdb.base/coredump-filter.exp: loading and testing corefile >> for non-Private-Anonymous: loading >> /home/sergio/work/src/git/binutils-gdb/rhbz1085906-coredump-filter/build-64-3/gdb/testsuite/gdb.base/non-private-anon.gcore >> spawn >> /home/sergio/work/src/git/binutils-gdb/rhbz1085906-coredump-filter/build-64-3/gdb/testsuite/../../gdb/gdb >> -nw -nx -data-directory >> /home/sergio/work/src/git/binutils-gdb/rhbz1085906-coredump-filter/build-64-3/gdb/testsuite/../data-directory >> ... >> >> GDB correctly loaded the corefile (despite the warnings), and the > > The error made the rest of core_open be skipped: if the core is still > loaded, gdb is potentially in an inconsistent state at this point. > I'd think we should completely discard the core/target if something > errors out. And then if we can be tolerant to specific parts of > loading a core failing, we should handle those before the error escapes > out of core_open. We do something like that > already (note core_close_cleanup and the TRY/CATCH'S), but it's clearly > not complete. After: > > push_target (&core_ops); > discard_cleanups (old_chain); > > ... several things can throw and let an exception escape. Yeah, certainly we should be catching those before they escape. I will see if I can take a look at more places to improve/fix later. >> Right, so I took some time and found the right fix, I think. As we >> agreed above, the fact that GDB is not printing the "Core was generated >> by..." message is really strange, so I decided to investigate why it is >> doing that. >> >> The answer is that we are forgetting to check for an exception on >> solib_svr4_r_ldsomap. When loading the corefile, GDB calls this >> function, which then calls read_memory_unsigned_integer, which throws an >> error. This error is not being caught by the function, so it propagates >> until the main loop catches it. The fix is obvious: we should catch >> this regression and continue in the function. With it, GDB now >> correctly prints the "Core was generated by..." message, and the patch >> to adjust gdb_core_cmd is no longer needed. >> >> Regression-tested on Fedora 20 for x86_64, i686 and native-gdbserver. >> >> Does that make more sense now? >> > > Yes, this is OK. Thanks, pushed: 416f679e68468ea6dd7384213994ce74201f82e7 -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/