Bug 12074

Summary: multi-inferior internal error
Product: gdb Reporter: Jan Kratochvil <jan>
Component: threadsAssignee: Not yet assigned to anyone <unassigned>
Severity: normal CC: gdb-prs, jan, pedro, tromey, tromey
Priority: P2    
Version: HEAD   
Target Milestone: ---   
Host: x86_64-fedora14-linux-gnu Target: x86_64-fedora14-linux-gnu
Build: Last reconfirmed: 2012-02-15 00:00:00

Description Jan Kratochvil 2010-09-30 15:08:40 UTC
gdb -n -ex 'core-file core' -ex add-inferior -ex 'inferior 2' -ex 'file sleep' \
       -ex r

Starting program: /bin/sleep 
inferior.c:362: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
Comment 1 Tom Tromey 2012-02-15 19:21:07 UTC
This worked in 7.2, failed in 7.3 and 7.4, and works again on HEAD.

I am reluctant to close it because even on HEAD it prints:

(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file sleep
warning: core file may not match specified executable file.

... but this inferior has nothing to do with the core file, presumably.
(Actually I am not 100% sure how this is supposed to work.)

Also, given the history of this bug we should have a test case for it.
Comment 2 Pedro Alves 2012-04-11 15:02:34 UTC
#1 - GDB doesn't support having multiple target stack active, so you can only debug multiple inferiors if they're all controlled by the same target.

#2 - The core target (corelow.c, mostly) doesn't support debugging multiple cores.  E.g., core_bfd is a global.

The original report is about issuing "run" while debugging a core, which due to the above would break.  As an intermediate step, GDB now pops the current target from the stack, along with getting rid of all its inferiors, when you switch to a ptrace-based target (IOW, core -> process).  Not ideal, but better than breaking down.

> (gdb) inferior 2
> [Switching to inferior 2 [<null>] (<noexec>)]
> (gdb) file sleep
> warning: core file may not match specified executable file.

Caused by the points above, mostly by #2 (core_bfd global).
Comment 3 Jan Kratochvil 2015-01-17 20:47:10 UTC
Still happens for: cf90fd9a07e8998540bf74f293d348a6653ac120
Comment 4 cvs-commit@gcc.gnu.org 2015-01-22 20:03:48 UTC
The master branch has been updated by Jan Kratochvil <jkratoch@sourceware.org>:


commit f0e8c4c5d1bce422ac86090b76c28931b0d240bf
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Thu Jan 22 21:02:24 2015 +0100

    Print current thread after loading a core file
    downstream Fedora request:
    	Please make it easier to find the backtrace of the crashing thread
    Currently after loading a core file GDB prints:
    Core was generated by `./threadcrash1'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    8       *(volatile int *)0=0;
    (gdb) _
    there is nowhere seen which of the threads had crashed.  In reality GDB always
    numbers that thread as #1 and it is the current thread that time.  But after
    dumping all the info into a file for later analysis it is no longer obvious.
    'thread apply all bt' even puts the thread #1 to the _end_ of the output!!!
    Should GDB always print after loading a core file what "thread" command would
    [Current thread is 1 (Thread 0x7fcbe28fe700 (LWP 15453))]
    BTW I think it will print the thread even when loading single/non-threaded
    core file when other inferior(s) exist.  But that currently crashes
    	[Bug threads/12074] multi-inferior internal error
    plus I think that would be a correct behavior anyway.
    2015-01-22  Jan Kratochvil  <jan.kratochvil@redhat.com>
    	* corelow.c (core_open): Call also thread_command.
    	* gdbthread.h (thread_command): New prototype moved from ...
    	* thread.c (thread_command): ... here.
    	(thread_command): Make it global.
Comment 5 Tom Tromey 2022-06-13 21:35:43 UTC
I think this was fixed by the multi-target work.