Description of problem: I've been chasing bug in gnome-terminal - which seems to be spinning on CPU, and instead of getting stacktrace - I've got abort from gdb. As a side note - why is there Python being used for my command line debugger tracing executable ? Version-Release number of selected component (if applicable): gdb-7.5.50.20130118-2.fc19.x86_64 How reproducible: Steps to Reproduce: 1. try to debug gnome-terminal-3.7.1-1.fc19.x86_64 2. when it's start to spin on CPU 3. Actual results: Expected results: Additional info:
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