Re: [PATCH v2 2/3] gdb/python: raise TypeError instead of abort on calling value method for label symbol object

[Maxim Bublis <satori@yandex-team.ru>]

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 <stdlib.h>

int main() {
    abort();

some_label:
    return 0;
}

I’m 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="python print list(gdb.selected_frame().older().older().block())[0].value(gdb.selected_frame().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 or 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 or 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’t look like some deeper problem in GDB for me, just incompleteness of Python API.
There is very similar “if” 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=0xbb2890 <internal_error_problem>, file=<optimized out>, line=248, fmt=<optimized out>, ap=0x7fff15a33d18) at utils.c:781
#4  0x00000000006719e9 in internal_verror (file=<optimized out>, line=<optimized out>, fmt=<optimized out>, ap=<optimized out>) at utils.c:797
#5  0x0000000000671a92 in internal_error (file=<optimized out>, line=<optimized out>, string=<optimized out>) at utils.c:807
#6  0x000000000054521b in store_typed_address (buf=<optimized out>, type=<optimized out>, addr=<optimized out>) at findvar.c:248
#7  store_typed_address (buf=0x1b15ad0 "", type=0x1abf680, addr=0) at findvar.c:244
#8  0x0000000000546090 in default_read_var_value (var=<optimized out>, frame=<optimized out>) at findvar.c:466
#9  0x00000000004ff939 in sympy_value (self=0x1b52fb0, args=<optimized out>) 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.so.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.so.1.0
#14 0x00007fba013676cb in PyRun_SimpleStringFlags () from /usr/lib/libpython2.7.so.1.0
#15 0x00000000004efefa in python_command (arg=<optimized out>, from_tty=<optimized out>) at ./python/python.c:477
#16 0x000000000066d58c in execute_command (p=<optimized out>, from_tty=0) at top.c:460
#17 0x00000000005a640f in catch_command_errors (command=0x66d330 <execute_command>,
    arg=0x7fff15a3480a "python print list(gdb.selected_frame().older().older().block())[0].value(gdb.selected_frame().older().older())", from_tty=0, mask=<optimized out>) at exceptions.c:551
#18 0x00000000005a9292 in captured_main (data=<optimized out>) at main.c:1030
#19 0x00000000005a634b in catch_errors (func=0x5a8c80 <captured_main>, func_args=0x7fff15a34390, errstring=0x77f7f6 "", mask=RETURN_MASK_ALL) at exceptions.c:524
#20 0x00000000005a9bbb in gdb_main (args=<optimized out>) at main.c:1062
#21 0x000000000045cc25 in main (argc=<optimized out>, argv=<optimized out>) 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: <gdb-patches-return-111832-listarch-gdb-patches=sources.redhat.com@sourceware.org>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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" <nicolas.blanc@intel.com>
To: Pedro Alves <palves@redhat.com>
CC: "gdb-patches@sourceware.org" <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 the inserted flag isn't clear, but likely to avoid breakpoint removal errors, assuming remove-symbol-file was called after the dynamic object was already unmapped from the inferior. 

Indeed that was the intend. The clearing of the flag copied from disable_breakpoints_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 objfile *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_USERLOADED))
> +  if ((objfile->flags & OBJF_USERLOADED) == 0)
>      return;

The comment above should be updated. The condition is  now weaker. 


   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 = 1;
> -	      loc->inserted = 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 = 
> + make_show_memory_breakpoints_cleanup (1);  val = target_read_memory 
> + (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