Bug 903522

Created attachment 686555 [details]
gdb backtrace  and  full backtrace

Bactrace from raised exception on internal error.

(gdb) 
terminal_notebook_scroll_event (widget=
../../gdb/solib-svr4.c:3154: internal-error: elf_lookup_lib_symbol: Assertion `objfile->separate_debug_objfile_backlink == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) ../../gdb/solib-svr4.c:3154: internal-error: elf_lookup_lib_symbol: Assertion `objfile->separate_debug_objfile_backlink == NULL' failed.

(In reply to comment #0)

> As a side note - why is there Python being used for my command line debugger
> tracing executable ?

If you mean why does it exist at all, the answer is to provide
better scripting capabilities and some long-requested features.

If you mean why you are seeing it in particular when debugging gnome-terminal,
the answer is probably that you are picking up the glib or gobject
Python helper code.  See /usr/share/gdb/auto-load/

Do you have the core file for GDB itself?

With the backtrace I can say only GDB memory corruption, it cannot happen:

elf_lookup_lib_symbol has:
    gdb_assert (objfile->separate_debug_objfile_backlink == NULL);
and OBJFILE can come only from its caller lookup_objfile_from_block which does:
    if (obj->separate_debug_objfile_backlink)
      obj = obj->separate_debug_objfile_backlink;

Yes - I do have gdb coredumps - but even bzip2 compressed they have over 14MB - should I attach them.


Maybe I could try next time I'll have 'spinning' gnome-terminal run  gdb within valgrind (if that will work) - since to me it looks like some memory corruption bug.

Looking at 3 coredumps from gdb I've not yet deleted - there is one slightly different.


#0  __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
#1  0x00007f62d11643f1 in PyString_FromFormatV () from /lib64/libpython2.7.so.1.0
#2  0x00007f62d11b55af in PyErr_Format () from /lib64/libpython2.7.so.1.0
#3  0x00000000004e8764 in gdbpy_convert_exception (exception=...) at ../../gdb/python/py-utils.c:302
#4  0x00000000004deccf in frapy_read_var (self=0x8b34330, args=<optimized out>) at ../../gdb/python/py-frame.c:452
#5  0x00007f62d11ac201 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#6  0x00007f62d11abe71 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#7  0x00007f62d11abe71 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#8  0x00007f62d11abe71 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#9  0x00007f62d11abe71 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#10 0x00007f62d11acc3f in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#11 0x00007f62d113c8b6 in ?? () from /lib64/libpython2.7.so.1.0
#12 0x00007f62d1118bbe in PyObject_Call () from /lib64/libpython2.7.so.1.0
#13 0x00007f62d1127190 in ?? () from /lib64/libpython2.7.so.1.0
#14 0x00007f62d1118bbe in PyObject_Call () from /lib64/libpython2.7.so.1.0
#15 0x00007f62d1119268 in PyObject_CallMethodObjArgs () from /lib64/libpython2.7.so.1.0
#16 0x00000000004e2eee in pretty_print_one_value (printer=printer@entry=0x8b04878, out_value=out_value@entry=0x7fff5fb8d818)
    at ../../gdb/python/py-prettyprint.c:224
#17 0x00000000004e34be in print_string_repr (gdbarch=0x2b8a560, language=0x7ae0a0 <c_language_defn>, options=0x7fff5fb8da50, recurse=2, 
    stream=0x6a148d0, hint=0x0, printer=0x8b04878) at ../../gdb/python/py-prettyprint.c:316
#18 apply_val_pretty_printer (type=type@entry=0x8c270f0, valaddr=valaddr@entry=0x9916690 "\220\340\066\001", 
    embedded_offset=embedded_offset@entry=0, address=address@entry=0, stream=stream@entry=0x6a148d0, recurse=recurse@entry=2, 
    val=val@entry=0x5de21a0, options=options@entry=0x7fff5fb8da50, language=language@entry=0x7ae0a0 <c_language_defn>)
    at ../../gdb/python/py-prettyprint.c:743
#19 0x000000000054b811 in val_print (type=0x8c270f0, valaddr=0x9916690 "\220\340\066\001", embedded_offset=embedded_offset@entry=0, address=0, 
    stream=stream@entry=0x6a148d0, recurse=recurse@entry=2, val=val@entry=0x5de21a0, options=options@entry=0x7fff5fb8da50, 
    language=language@entry=0x7ae0a0 <c_language_defn>) at ../../gdb/valprint.c:762
#20 0x000000000054b8fb in common_val_print (val=0x5de21a0, stream=stream@entry=0x6a148d0, recurse=recurse@entry=2, 
    options=options@entry=0x7fff5fb8da50, language=language@entry=0x7ae0a0 <c_language_defn>) at ../../gdb/valprint.c:841
#21 0x000000000057f832 in print_frame_arg (arg=arg@entry=0x7fff5fb8dae0) at ../../gdb/stack.c:282
#22 0x0000000000580548 in print_frame_args (func=<optimized out>, frame=frame@entry=0x825b320, num=num@entry=-1, stream=0x29a70a0)
    at ../../gdb/stack.c:652

(In reply to comment #2)
> (In reply to comment #0)
> 
> > As a side note - why is there Python being used for my command line debugger
> > tracing executable ?
> 
> If you mean why does it exist at all, the answer is to provide
> better scripting capabilities and some long-requested features.
> 
> If you mean why you are seeing it in particular when debugging
> gnome-terminal,
> the answer is probably that you are picking up the glib or gobject
> Python helper code.  See /usr/share/gdb/auto-load/

Is there a way to run  gdb without  python being loaded?

i.e. if I may suspect bug in the python part of gdb - am I able to try with some config option to skip 'better scripting' and use pure C code ?

(In reply to comment #4)
> Yes - I do have gdb coredumps - but even bzip2 compressed they have over
> 14MB - should I attach them.

Yes, if possible.  Or you can put it on any other location.
(BTW xz -9e is more effective. :-) )


> Maybe I could try next time I'll have 'spinning' gnome-terminal run  gdb
> within valgrind (if that will work) - since to me it looks like some memory
> corruption bug.

You can also make gcore of that gnome-terminal, if GDB crashes even on its core file.


> Looking at 3 coredumps from gdb I've not yet deleted - there is one slightly
> different.

This is a different bug, it would be great to post it as a new Bug, possibly also with a GDB core file (or gnome-terminal core file, if it reproduces the GDB bug).

Created attachment 690795 [details]
xz -9e compressed gdb coredump

[patch] Fix assert crashes with minidebuginfo
http://sourceware.org/ml/gdb-patches/2013-02/msg00016.html