From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29278 invoked by alias); 16 Apr 2014 17:20:53 -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 29238 invoked by uid 89); 16 Apr 2014 17:20:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: forward-corp1e.mail.yandex.net Received: from forward-corp1e.mail.yandex.net (HELO forward-corp1e.mail.yandex.net) (77.88.60.199) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 16 Apr 2014 17:20:50 +0000 Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id ED785640320; Wed, 16 Apr 2014 21:20:46 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id B5B8D2C0802; Wed, 16 Apr 2014 21:20:46 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:408:2444:60ce:9aec:3dc5]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id kDkOUs1zkY-KkNqZRVc; Wed, 16 Apr 2014 21:20:46 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: c896a3d6-348c-4214-819a-67c7831c55f0 Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH v2 2/3] gdb/python: raise TypeError instead of abort on calling value method for label symbol object From: Maxim Bublis In-Reply-To: <534B9118.9010307@redhat.com> Date: Wed, 16 Apr 2014 17:20:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <8DDE7431-40A7-4C4F-9681-E60A712710A1@yandex-team.ru> References: <1394026864-4691-1-git-send-email-satori@yandex-team.ru> <1394026864-4691-2-git-send-email-satori@yandex-team.ru> <534B9118.9010307@redhat.com> To: Phil Muldoon X-SW-Source: 2014-04/txt/msg00321.txt.bz2 Hi, Phil. > I am really curious about the sigabort you were seeing. Without it I > cannot tell if there is a deeper problem in GDB, which this patch > would be papering over. Can you provide the backtrace? For example, we have the following code: #include int main() { abort(); some_label: return 0; } I=92m inspecting coredump, generated by executable compiled from code above= , using Python API in *batch* mode: $ gdb/bin/gdb a.out a.out.19605.6 --batch --eval-command=3D"python print li= st(gdb.selected_frame().older().older().block())[0].value(gdb.selected_fram= e().older().older())" [New LWP 19605] Core was generated by `./a.out'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f4a28ee7425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 findvar.c:248: internal-error: store_typed_address: type is not a pointer o= r reference A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] findvar.c:248: internal-error: store_typed_address: type is not a pointer o= r reference A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) [answered Y; input not from terminal] Aborted (core dumped) So, it doesn=92t look like some deeper problem in GDB for me, just incomple= teness of Python API. There is very similar =93if=94 condition for LOC_TYPEDEF in patched code. Sure, here is backtrace from GDB coredump: (gdb) bt #0 0x00007fba00d56425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fba00d59b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x000000000066f476 in dump_core () at utils.c:612 #3 0x00000000006717e9 in internal_vproblem (problem=3D0xbb2890 , file=3D, line=3D248, fmt=3D, a= p=3D0x7fff15a33d18) at utils.c:781 #4 0x00000000006719e9 in internal_verror (file=3D, line=3D<= optimized out>, fmt=3D, ap=3D) at utils.c:797 #5 0x0000000000671a92 in internal_error (file=3D, line=3D, string=3D) at utils.c:807 #6 0x000000000054521b in store_typed_address (buf=3D, type= =3D, addr=3D) at findvar.c:248 #7 store_typed_address (buf=3D0x1b15ad0 "", type=3D0x1abf680, addr=3D0) at= findvar.c:244 #8 0x0000000000546090 in default_read_var_value (var=3D, fr= ame=3D) at findvar.c:466 #9 0x00000000004ff939 in sympy_value (self=3D0x1b52fb0, args=3D) at ./python/py-symbol.c:277 #10 0x00007fba013a65d5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.= so.1.0 #11 0x00007fba013666b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.s= o.1.0 #12 0x00007fba013669e2 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.= 1.0 #13 0x00007fba01366a7c in PyRun_StringFlags () from /usr/lib/libpython2.7.s= o.1.0 #14 0x00007fba013676cb in PyRun_SimpleStringFlags () from /usr/lib/libpytho= n2.7.so.1.0 #15 0x00000000004efefa in python_command (arg=3D, from_tty= =3D) at ./python/python.c:477 #16 0x000000000066d58c in execute_command (p=3D, from_tty=3D= 0) at top.c:460 #17 0x00000000005a640f in catch_command_errors (command=3D0x66d330 , arg=3D0x7fff15a3480a "python print list(gdb.selected_frame().older().ol= der().block())[0].value(gdb.selected_frame().older().older())", from_tty=3D= 0, mask=3D) at exceptions.c:551 #18 0x00000000005a9292 in captured_main (data=3D) at main.c:= 1030 #19 0x00000000005a634b in catch_errors (func=3D0x5a8c80 , fu= nc_args=3D0x7fff15a34390, errstring=3D0x77f7f6 "", mask=3DRETURN_MASK_ALL) = at exceptions.c:524 #20 0x00000000005a9bbb in gdb_main (args=3D) at main.c:1062 #21 0x000000000045cc25 in main (argc=3D, argv=3D) at gdb.c:33 >From gdb-patches-return-111832-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Apr 16 17:21:53 2014 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 30538 invoked by alias); 16 Apr 2014 17:21:53 -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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 30526 invoked by uid 89); 16 Apr 2014 17:21:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Apr 2014 17:21:52 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 16 Apr 2014 10:21:06 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga002.fm.intel.com with ESMTP; 16 Apr 2014 10:21:02 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.58]) by IRSMSX103.ger.corp.intel.com ([163.33.3.157]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 18:18:31 +0100 From: "Blanc, Nicolas" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] Stale breakpoint instructions, spurious SIGTRAPS. Date: Wed, 16 Apr 2014 17:21:00 -0000 Message-ID: <388084C8C1E6A64FA36AD1D656E4856635AE8EB5@IRSMSX106.ger.corp.intel.com> References: <1397585886-29261-1-git-send-email-palves@redhat.com> In-Reply-To: <1397585886-29261-1-git-send-email-palves@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00322.txt.bz2 Content-length: 2256 Hi Pedro, > Then, the reason that disable_breakpoints_in_freed_objfile was clearing t= he inserted flag isn't clear, but likely to avoid breakpoint removal errors= , assuming remove-symbol-file was called after the dynamic object was alrea= dy unmapped from the inferior.=20 Indeed that was the intend. The clearing of the flag copied from disable_br= eakpoints_in_unloaded_shlib. > Comments? The suggestion makes sense to me. Thanks for looking into this. > if (val) > @@ -7666,7 +7693,7 @@ disable_breakpoints_in_freed_objfile (struct objfil= e *objfile) > ? /* If the file is a shared library not loaded by the user then > solib_unloaded was notified and disable_breakpoints_in_unloaded_shlib > was called. In that case there is no need to take action again. */ > - if ((objfile->flags & OBJF_SHARED) && !(objfile->flags & OBJF_USERLOAD= ED)) > + if ((objfile->flags & OBJF_USERLOADED) =3D=3D 0) > return; The comment above should be updated. The condition is now weaker.=20 ALL_BREAKPOINTS (b) @@ -7698,7 +7725,11 @@ disable_breakpoints_in_freed_objfile (struct objfile= *objfile) > if (is_addr_in_objfile (loc_addr, objfile)) > { > loc->shlib_disabled =3D 1; > - loc->inserted =3D 0; > + /* At this point, we don't know whether the object was > + unmapped from the inferior or not, so leave the > + inserted flag alone. We'll handle failure to > + uninsert quietly, in case the object was indeed > + unmapped. */ Would it work to simplify disable_breakpoints_in_unloaded_shlib in the same= way? Note that I understand it might be unnecessary risky to fix a function that= is not broken. > + /* Make sure we see the memory breakpoints. */ cleanup =3D=20 > + make_show_memory_breakpoints_cleanup (1); val =3D target_read_memory=20 > + (addr, old_contents, bplen); It was not immediately clear to me that old_contents means current content. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052