This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: random gdb errors: corruption of nptl_db event buffers ?
In case someone ever gets the same kind of error, more long hours of
debugging show that, indeed, this kind of error message comes from the
inferior clobbering one of its thread descriptors, and thus,
clobbering the descriptor's nptl_db event buffer and thus confusing
gdb. Fun.
Mathieu
On Sat, Jul 25, 2009 at 7:05 PM, Mathieu Lacage<mathieu.lacage@gmail.com> wrote:
> hi,
>
> I am trying to debug some random errors I get from gdb while debugging
> my program. No, the bug is not in gdb, it's in the inferior process
> but it appears that the inferior process is confusing ntpl_db beyond
> repair. All of this is threading related (hence, most likely, the
> random errors/crashes I observe). My program appears to be crashing
> somewhere in the code of a newly-created thread. Sometimes, it's the
> master thread join which crashes...
>
> On the gdb side, I get many different kinds of errors, all of which
> appear to the related to nptl_db events. Sometimes, gdb gets TD_DBERR
> from td_ta_event_getmsg. Sometimes, gdb something like the backtrace
> below which I interpret as gdb getting an invalid TD_CREATE event from
> the inferior, (potentially, with an invalid thread pointer).
>
> the error message:
>
> warning: Can't attach LWP -136336208: No such process
> ../../gdb/linux-thread-db.c:288: internal-error:
> thread_get_info_callback: Assertion `thread_info != NULL' failed.
>
> the associated backtrace:
>
> #0 Â0x0000003f5d8d1320 in __read_nocancel () from /lib64/libc.so.6
> #1 Â0x0000003f5d8717f8 in _IO_new_file_underflow (fp=0x3f5db686a0) at
> fileops.c:598
> #2 Â0x0000003f5d87328e in _IO_default_uflow (fp=0x0) at genops.c:440
> #3 Â0x0000003f5d86e82b in _IO_getc (fp=0x3f5db686a0) at getc.c:41
> #4 Â0x0000000000453502 in defaulted_query (ctlstr=<value optimized
> out>, defchar=0x0,
> Â Âargs=<value optimized out>) at ../../gdb/utils.c:1480
> #5 Â0x00000000004536ad in query (ctlstr=0x0) at ../../gdb/utils.c:1571
> #6 Â0x0000000000453866 in internal_vproblem (problem=0x9e6840,
> file=<value optimized out>,
> Â Âline=<value optimized out>, fmt=<value optimized out>, ap=<value
> optimized out>)
> Â Âat ../../gdb/utils.c:935
> #7 Â0x0000000000453919 in internal_verror (file=<value optimized out>,
> line=<value optimized out>,
> Â Âfmt=<value optimized out>, ap=0x3f5db69e10) at ../../gdb/utils.c:986
> #8 Â0x00000000004539b1 in internal_error (file=0x0, line=0x568b8000,
> Â Âstring=0x400 <Address 0x400 out of bounds>) at ../../gdb/utils.c:995
> #9 Â0x0000000000479335 in thread_get_info_callback
> (thp=0x7fffaddb3720, infop=0x7fffaddb3738)
> Â Âat ../../gdb/linux-thread-db.c:288
> #10 0x0000000000479e0e in thread_from_lwp (ptid={pid = 0x20f5, lwp =
> 0x20f6, tid = 0x0})
> Â Âat ../../gdb/linux-thread-db.c:329
> #11 thread_db_wait (ptid={pid = 0x20f5, lwp = 0x20f6, tid = 0x0}) at
> ../../gdb/linux-thread-db.c:922
> #12 0x00000000005339aa in target_wait (ptid={pid = 0xffffffff, lwp =
> 0x0, tid = 0x0},
> Â Âstatus=0x7fffaddb3850) at ../../gdb/target.c:1889
> #13 0x000000000050f42e in wait_for_inferior
> (treat_exec_as_sigtrap=0x0) at ../../gdb/infrun.c:1850
> #14 0x000000000050f95f in proceed (addr=<value optimized out>,
> siggnal=TARGET_SIGNAL_DEFAULT, step=0x0)
> Â Âat ../../gdb/infrun.c:1479
> #15 0x0000000000506738 in continue_command (args=0x0, from_tty=0x1) at
> ../../gdb/infcmd.c:745
> #16 0x0000000000451969 in execute_command (p=0x1590101 "",
> from_tty=0x1) at ../../gdb/top.c:450
> #17 0x000000000051c2f5 in command_handler (command=0x1590100 "c") at
> ../../gdb/event-top.c:519
> #18 0x000000000051cfbc in command_line_handler (rl=<value optimized
> out>) at ../../gdb/event-top.c:744
> #19 0x0000003f5fc27e2c in rl_callback_read_char () at ../callback.c:205
> #20 0x000000000051c439 in rl_callback_read_char_wrapper
> (client_data=0x0) at ../../gdb/event-top.c:179
> #21 0x000000000051ad98 in process_event () at ../../gdb/event-loop.c:394
> #22 0x000000000051bf8a in gdb_do_one_event (data=<value optimized
> out>) at ../../gdb/event-loop.c:459
> #23 0x00000000005160bb in catch_errors (func=<value optimized out>,
> func_args=<value optimized out>,
> Â Âerrstring=<value optimized out>, mask=<value optimized out>) at
> ../../gdb/exceptions.c:516
> #24 0x00000000004a6ce8 in tui_command_loop (data=<value optimized out>)
> Â Âat ../../gdb/tui/tui-interp.c:156
> #25 0x00000000004449c9 in captured_command_loop (data=0x0) at
> ../../gdb/main.c:183
> #26 0x00000000005160bb in catch_errors (func=<value optimized out>,
> func_args=<value optimized out>,
> Â Âerrstring=<value optimized out>, mask=<value optimized out>) at
> ../../gdb/exceptions.c:516
> #27 0x000000000044533e in captured_main (data=<value optimized out>)
> at ../../gdb/main.c:989
> #28 0x00000000005160bb in catch_errors (func=<value optimized out>,
> func_args=<value optimized out>,
> Â Âerrstring=<value optimized out>, mask=<value optimized out>) at
> ../../gdb/exceptions.c:516
> #29 0x00000000004449b4 in gdb_main (args=0x7ff9568b8000) at ../../gdb/main.c:999
> #30 0x0000000000444989 in main (argc=<value optimized out>,
> argv=0x7ff9568b8000) at ../../gdb/gdb.c:47
>
> Anyway, I have spent a considerable amount of time trying to trace
> what is going on, and trying to figure out how I can possibly inflict
> so much pain to gdb from the inferior process but I am still out of
> luck so, maybe someone who have more experience with debugging nptl or
> ntpl_db could give me a hint as to what I could be doing so badly.
> Would really corrupting the inferior process' nptl event buffer
> trigger this kind of crap ?
>
> Mathieu
> --
> Mathieu Lacage <mathieu.lacage@gmail.com>
>
--
Mathieu Lacage <mathieu.lacage@gmail.com>