[Bug threads/12074] multi-inferior internal error

[Bug threads/12074] multi-inferior internal error

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12074

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-15
                 CC|                            |tromey at redhat dot com
     Ever Confirmed|0                           |1

--- Comment #1 from Tom Tromey <tromey at redhat dot com> 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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug threads/12074] multi-inferior internal error

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12074

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> 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).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug threads/12074] multi-inferior internal error

[jan.kratochvil at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12074

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com

--- Comment #3 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Still happens for: cf90fd9a07e8998540bf74f293d348a6653ac120

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/12074] multi-inferior internal error

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12074

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Kratochvil <jkratoch@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f0e8c4c5d1bce422ac86090b76c28931b0d240bf

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
        https://bugzilla.redhat.com/show_bug.cgi?id=1024504

    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
    print?
    [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
        https://sourceware.org/bugzilla/show_bug.cgi?id=12074
    plus I think that would be a correct behavior anyway.

    gdb/ChangeLog
    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/12074] multi-inferior internal error

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12074

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |tromey at sourceware dot org

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
I think this was fixed by the multi-target work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.