usefulness of "you won't be able to access this core file until you terminate your ..."
Pedro Alves
pedro@codesourcery.com
Mon Aug 11 13:20:00 GMT 2008
I apologise, if I sounded ranty. It wasn't intended. I was really
surprised to see this behaviour. :-(
Here's a patch to fix the issues above:
[Get rid of previous targets in target_preopen]
http://sourceware.org/ml/gdb-patches/2008-08/msg00292.html
Thanks,
--
Pedro Alves
On Monday 11 August 2008 01:31:54, Pedro Alves wrote:
> Can anybody explain to me the usefulness of keeping an upper layer around
> when opening a new core file?
> We're conceptually loading a new inferior,
> and setting up a new target stack to access it. Why would you want to
> leave an inferface into the previous inferior, which surelly may not make
> sense for the new inferior?
>
> If I'm debugging a multi-threaded OpenBSD core, which loads bsd-uthreads,
> and the I do "core single-thread.core", to load a core file for a program
> that didn't link with the thread library, I get that warning. But, why
> would anybody want to keep any target_stratum >= process_stratum around
> then ?
>
> In corelow.c:
>
> static void
> core_open (filename, from_tty)
> char *filename;
> int from_tty;
> {
> (...)
>
> ontop = !push_target (&core_ops);
> discard_cleanups (old_chain);
>
> (...)
>
> /* Build up thread list from BFD sections. */
>
> init_thread_list ();
> bfd_map_over_sections (core_bfd, add_to_thread_list,
> bfd_get_section_by_name (core_bfd, ".reg"));
>
> if (ontop)
> {
> (...)
> }
> else
> {
> warning (
> "you won't be able to access this core file until you terminate\n\
> your %s; do ``info files''", target_longname);
> }
> }
>
> IMO, the pop_target below should be make unconditional, since
> when I'm debugging a multi-threaded core, even though I loaded
> the thread_stratum layer, it doesn't have target_has_execution.
> And, it should be a pop_all_targets or similar call. The question is,
> again, why would anybody want to leave the thread_stratum, or anything
> else above core_stratum around?
>
> void
> target_preopen (int from_tty)
> {
> dont_repeat ();
>
> if (target_has_execution)
> {
> if (!from_tty
>
> || query (_("A program is being debugged already. Kill it? ")))
>
> target_kill ();
> else
> error (_("Program not killed."));
> }
>
> /* Calling target_kill may remove the target from the stack. But if
> it doesn't (which seems like a win for UDI), remove it now. */
>
> if (target_has_execution)
> pop_target ();
>
> target_pre_inferior (from_tty);
> }
>
> This issue doesn't happen normally when going from a running
> multi-threaded inferior -> single-threaded core, because the
> target_kill above pops the whole stack out.
>
> Linux: running thread-db app -> single-threaded core
>
> >gdb --quiet /home/pedro/gdb/tests/threads
>
> (gdb) start
> Breakpoint 1 at 0x400640: file threads.c, line 35.
> Starting program: /home/pedro/gdb/tests/threads
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7f7eaf8916e0 (LWP 17234)]
> [Switching to Thread 0x7f7eaf8916e0 (LWP 17234)]
> main () at threads.c:35
> 35 long i = 0;
> (gdb) maint print target-stack
> The current target stack is:
> - multi-thread (multi-threaded child process.)
> - child (Unix child process)
> - exec (Local exec file)
> - None (None)
> (gdb) core gdb/gdb.core
> A program is being debugged already. Kill it? (y or n) y
> warning: core file may not match specified executable file.
> warning: Temporarily disabling breakpoints for unloaded shared
> library "/lib/libpthread.so.0"
> warning: Temporarily disabling breakpoints for unloaded shared
> library "/lib/libc.so.6"
> Symbols already loaded for /lib64/ld-linux-x86-64.so.2
>
> Core was generated by `/home/pedro/gdb/multi_process/build/gdb/gdb'.
> Program terminated with signal 5, Trace/breakpoint trap.
> [New process 16607]
> #0 0x000000000044ee87 in ?? ()
> (gdb) maint print target-stack
> The current target stack is:
> - core (Local core dump file)
> - exec (Local exec file)
> - None (None)
> (gdb)
>
> OpenBSD multi-threaded core -> single-threaded core
>
> >./gdb --quiet ./crash -c ./crash.core
>
> Reading symbols from /usr/lib/libpthread.so.9.0...done.
> Loaded symbols for /usr/lib/libpthread.so.9.0
> Symbols already loaded for /usr/lib/libpthread.so.9.0
> Reading symbols from /usr/lib/libc.so.43.0...done.
> Loaded symbols for /usr/lib/libc.so.43.0
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> Core was generated by `crash'.
> Program terminated with signal 11, Segmentation fault.
> [New process 1, thread 0x8874a400]
> ...
> #0 _thread_kern_sched (scp=0xcfbf077c)
> at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
> 482 /usr/src/lib/libpthread/uthread/uthread_kern.c: No such file or
> directory.
> in /usr/src/lib/libpthread/uthread/uthread_kern.c
> Setting up the environment for debugging gdb.
> Function "internal_error" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) [answered
> N; input not from terminal]
> Function "info_command" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) [answered
> N; input not from terminal]
> /net/home/pedro/gdb/multi_process/build-openbsd43/gdb/.gdbinit:8: Error in
> sourced command file:
> No breakpoint number 0.
> (gdb) maint print target-stack
> The current target stack is:
> - bsd-uthreads (BSD user-level threads)
> - core (Local core dump file)
> - exec (Local exec file)
> - None (None)
>
> (gdb) core crashst.core
> Core was generated by `crashst'.
> Program terminated with signal 11, Segmentation fault.
> warning: you won't be able to access this core file until you terminate
> your BSD user-level threads; do ``info files''
> (gdb) maint print target-stack
> The current target stack is:
> - bsd-uthreads (BSD user-level threads)
> - core (Local core dump file)
> - exec (Local exec file)
> - None (None)
>
> ??????
>
> I can come up with more weird cases:
>
> target remote -> target core
>
> shell1$ ./gdbserver :9999 ./gdbserver
>
> shell2$ gdb --quiet ./gdbserver/gdbserver
> (gdb) tar remote :9999
> Remote debugging using :9999
> [New Thread 17988]
> 0x00007f9d5e167a60 in ?? () from /lib64/ld-linux-x86-64.so.2
> (gdb) core gdb.core
> A program is being debugged already. Kill it? (y or n) y
> warning: core file may not match specified executable file.
> Symbols already loaded for /lib64/ld-linux-x86-64.so.2
>
> Core was generated by `/home/pedro/gdb/multi_process/build/gdb/gdb'.
> Program terminated with signal 5, Trace/breakpoint trap.
> [New process 16607]
> #0 0x000000000044ee87 in ?? ()
> (gdb)
>
> Ok, that got rid of the remote target due to having target_has_execution.
>
> But,
>
> target extended-remote, no inferior -> target core
>
> shell1$ ./gdbserver --multi :9999
>
> shell2$ gdb
> (gdb) tar extended-remote :9999
> Remote debugging using :9999
> (gdb) core gdb.core
> (no debugging symbols found)
> Core was generated by `/home/pedro/gdb/multi_process/build/gdb/gdb'.
> Program terminated with signal 5, Trace/breakpoint trap.
> [New Thread 16607]
> warning: you won't be able to access this core file until you terminate
> your Extended remote serial target in gdb-specific protocol; do ``info
> files'' Remote failure reply: E01
> (gdb)
>
> (Geesh, we really should split the notion of target interface vs
> target inferior).
--
Pedro Alves
More information about the Gdb-patches
mailing list