> Now I detach immediately and try to attach to the child:

In this case, the inferior still has the parent's executable loaded:

...
> Attaching to program: ...bin/firefox, process 8189
                               ^^^^^^^

while in this case, you don't have an executable loaded, and so GDB
fetches the right one:

> However, if I quit gdb and attach to the child, it works.
...
> Reading symbols from ...bin/plugin-container...done.
                              ^^^^^^^^^^^^^^^^

(In reply to Pedro Alves from comment #1)

> while in this case, you don't have an executable loaded, and so GDB
> fetches the right one:

Thanks Pedro.
I am bit by this every couple of years and seemingly
can't remember the symptoms.
I've even filed it before (I thought more than once, since
IIRC I wrote a patch a long time ago... but I could only
find bug 16266 this time).

*** This bug has been marked as a duplicate of bug 16266 ***

We're discussing this here:

 https://sourceware.org/ml/gdb-patches/2015-05/msg00090.html

Version 2 patch here:

 https://sourceware.org/ml/gdb-patches/2015-06/msg00080.html

(In reply to Gary Benson from comment #4)
> Version 2 patch here:
> 
>  https://sourceware.org/ml/gdb-patches/2015-06/msg00080.html

I'm curious why it doesn't check the buildid.
It seems to me that if the current file has a buildid
and the attach target has a buildid, and they do not match,
then discarding the current file is the best thing to do.
My recollection is that gdb can't always do this because
(on systems without buildid) the user might have meant to do
this weird thing.  But when buildid is available can it ever
be meaningful?

The master branch has been updated by Philippe Waroquiers <philippe@sourceware.org>:

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

commit a2fedca99c622e1b523046d09f573b06de0207a6
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date:   Sat Dec 21 10:55:11 2019 +0100

    Implement 'set/show exec-file-mismatch'.
    
    This option allows to tell GDB to detect and possibly handle mismatched exec-files.
    
    A recurrent problem with GDB is that GDB uses the wrong exec-file
    when using the attach/detach commands successively.
    Also, in case the user specifies a file on the command line but attaches
    to the wrong PID, this error is not made visible and gives a not user
    understandable behaviour.
    
    For example:
      $ gdb
      ...
      (gdb) atta 2682  ############################################  PID running 'sleepers' executable
      Attaching to process 2682
      [New LWP 2683]
      [New LWP 2684]
      [New LWP 2685]
      [Thread debugging using libthread_db enabled]
      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
      0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84
      84    ../sysdeps/unix/syscall-template.S: No such file or directory.
      (gdb) det
      Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682
      [Inferior 1 (process 2682) detached]
      (gdb) atta 31069 ############################################  PID running 'gdb' executable
      Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
      Reading symbols from /lib64/ld-linux-x86-64.so.2...
      Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
      0x00007f43c23478a0 in ?? ()
      (gdb) bt
      #0  0x00007f43c23478a0 in ?? ()
      #1  0x0000558909e3ad91 in ?? ()
      #2  0x0000202962646700 in ?? ()
      #3  0x00007ffc69c74e70 in ?? ()
      #4  0x000055890c1d2350 in ?? ()
      #5  0x0000000000000000 in ?? ()
      (gdb)
    
    The second attach has kept the executable of the first attach.
    (in this case, 31069 is the PID of a GDB, that has nothing to do
    with the first determined 'sleepers' executable).
    
    Similarly, if specifying an executable, but attaching to a wrong pid,
    we get:
    
      gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
      ...
      Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers...
      (gdb) atta 31069 ############################################  PID running 'gdb' executable
      Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
      Reading symbols from /lib64/ld-linux-x86-64.so.2...
      Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
      0x00007f43c23478a0 in ?? ()
      (gdb) bt
      #0  0x00007f43c23478a0 in ?? ()
      #1  0x0000558909e3ad91 in ?? ()
      #2  0x0000202962646700 in ?? ()
      #3  0x00007ffc69c74e70 in ?? ()
      #4  0x000055890c1d2350 in ?? ()
      #5  0x0000000000000000 in ?? ()
      (gdb)
    
    And it is unclear to the user what has happened/what is going wrong.
    
    This patch series implements a new option:
        (gdb) apropos exec-file-mismatch
        set exec-file-mismatch -- Set exec-file-mismatch handling (ask|warn|off).
        show exec-file-mismatch -- Show exec-file-mismatch handling (ask|warn|off).
        (gdb) help set exec-file-mismatch
        Set exec-file-mismatch handling (ask|warn|off).
        Specifies how to handle a mismatch between the current exec-file name
        loaded by GDB and the exec-file name automatically determined when attaching
        to a process:
    
         ask  - warn the user and ask whether to load the determined exec-file.
         warn - warn the user, but do not change the exec-file.
         off  - do not check for mismatch.
    
    "ask" means: in case of mismatch between the current exec-file name
    and the automatically determined exec-file name of the PID we are attaching to,
    give a warning to the user and ask whether to load the automatically determined
    exec-file.
    
    "warn" means: in case of mismatch, just give a warning to the user.
    
    "off" means: do not check for mismatch.
    
    This fixes PR gdb/17626.
    There was a previous trial to fix this PR.
    See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html
    This trial was however only fixing the problem for the automatically
    determined executable files when doing attach.
    It was differentiating the 'user specified executable files' ("sticky")
    from the executable files automatically found by GDB.
    But such user specified sticky executables are in most cases due
    to a wrong manipulation by the user, giving unexpected results
    such as backtrace showing no function like in the above example.
    
    This patch ensures that whenever a process executable can be
    determined, that the user is warned if there is a mismatch.
    
    The same tests as above then give:
    
      (gdb) atta 2682
      Attaching to process 2682
      [New LWP 2683]
      [New LWP 2684]
      [New LWP 2685]
      [Thread debugging using libthread_db enabled]
      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
      0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84
      84    ../sysdeps/unix/syscall-template.S: No such file or directory.
      (gdb) det
      Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682
      [Inferior 1 (process 2682) detached]
      (gdb) atta 31069
      Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
      warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
      and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb
      exec-file-mismatch handling is currently "ask"
      Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y
      Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb...
      Setting up the environment for debugging gdb.
      ...
      Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
      0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
      84    ../sysdeps/unix/syscall-template.S: No such file or directory.
      (top-gdb) bt
      During symbol reading: incomplete CFI data; unspecified registers (e.g., rax) at 0x7f43c23478ad
      During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'
      During symbol reading: cannot get low and high bounds for subprogram DIE at 0x12282a7
      During symbol reading: Child DIE 0x12288ba and its abstract origin 0x1228b26 have different parents
      During symbol reading: DW_AT_call_target target DIE has invalid low pc, for referencing DIE 0x1229540 [in module /bd/home/philippe/gdb/git/build_fixes/gdb/gdb]
      #0  0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
      #1  0x0000558909e3ad91 in poll (__timeout=-1, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
      #2  gdb_wait_for_event (block=block@entry=1) at ../../fixes/gdb/event-loop.c:772
      #3  0x0000558909e3aef4 in gdb_do_one_event () at ../../fixes/gdb/event-loop.c:347
      #4  0x0000558909e3b085 in gdb_do_one_event () at ../../fixes/gdb/common/common-exceptions.h:219
      #5  start_event_loop () at ../../fixes/gdb/event-loop.c:371
      During symbol reading: Member function "~_Sp_counted_base" (offset 0x1c69bf7) is virtual but the vtable offset is not specified
      During symbol reading: Multiple children of DIE 0x1c8f5a0 refer to DIE 0x1c8f0ee as their abstract origin
      #6  0x0000558909ed3b78 in captured_command_loop () at ../../fixes/gdb/main.c:331
      #7  0x0000558909ed4b6d in captured_main (data=<optimized out>) at ../../fixes/gdb/main.c:1174
      #8  gdb_main (args=<optimized out>) at ../../fixes/gdb/main.c:1190
      #9  0x0000558909c1e9a8 in main (argc=<optimized out>, argv=<optimized out>) at ../../fixes/gdb/gdb.c:32
      (top-gdb)
    
      gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
      ...
      Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers...
      (gdb) atta 31069
      Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
      warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
      and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb
      exec-file-mismatch handling is currently "ask"
      Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y
      Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb...
      Setting up the environment for debugging gdb.
      ....
    
    In other words, it now works as intuitively expected by the user.
    If ever the user gave the correct executable on the command line,
    then attached to the wrong pid, then confirmed loading the wrong executable,
    the user can simply fix this by detaching, and attaching to the correct pid,
    GDB will then tell again to the user that the exec-file might better
    be loaded.
    
    The default value of "ask" is chosen instead of e.g. "warn" as in most
    cases, switching of executable will be the correct action,
    and in any case, the user can decide to not load the executable,
    as GDB asks a confirmation to the user to load the new executable.
    
    For settings "ask" and "warn", the new function validate_exec_file ()
    tries to get the inferior pid exec file and compares it with the current
    exec file.  In case of mismatch, it warns the user and optionally load
    the executable.
    This function is called in the attach_command implementation to cover
    most cases of attaching to a running process.
    It must also be called in remote.c, as the attach command is not supported
    for all types of remote gdbserver.
    
    gdb/ChangeLog
    2020-01-25  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
    
    	* exec.c (exec_file_mismatch_names, exec_file_mismatch_mode)
    	(show_exec_file_mismatch_command, set_exec_file_mismatch_command)
    	(validate_exec_file): New variables, enums, functions.
    	(exec_file_locate_attach, print_section_info): Style the filenames.
    	(_initialize_exec): Install show_exec_file_mismatch_command and
    	 set_exec_file_mismatch_command.
    	* gdbcore.h (validate_exec_file): Declare.
    	* infcmd.c (attach_command): Call validate_exec_file.
    	* remote.c ( remote_target::remote_add_inferior): Likewise.

(In reply to Sourceware Commits from comment #6)
>     This fixes PR gdb/17626.

Sounds like this can be closed?

Seems like it.