Re: [patch] Do not close BFDs, breaking deleted inferior shlibs

[Doug Evans <dje at google dot com>]

On Mon, Feb 16, 2015 at 1:09 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> ------------------------------------------------------------------------------
> https://bugzilla.redhat.com/show_bug.cgi?id=1170861
>
> Ulrich Drepper 2014-12-05 19:02:47 CET
>
> Here is a self-contained reproducer:
>
> #include <dlfcn.h>
> #include <stdlib.h>
> int main() {
>   system("echo 'int foo() { return foo(); }' | gcc -x c -shared -fpic -o u.so -");
>   void *d = dlopen("./u.so", RTLD_LAZY);
>   if (d == NULL) {
>     puts(dlerror());
>     return 1;
>   }
>   unlink("u.so");
>   int (*fp)(void) = (int(*)(void)) dlsym(d, "foo");
>   return fp();
> }
>
> Run this under gdb and then just execute "p $pc".  Notice that the program crashes due to a stack overrun.  If you have this error in the executable itself it'll work fine.
>
> The problem is that the DSO goes away before gdb reads the debug info.  This happens, for instance, with gcc's JIT.
>
> ------------------------------------------------------------------------------
>
> continue
> Continuing.
> Program received signal SIGUSR1, User defined signal 1.
> 0x0000003424e348c7 in __GI_raise (BFD: reopening .../gdb/testsuite/gdb.base/close-deleted-bfd-solib.so: No such file or directory
> BFD: reopening .../gdb/testsuite/gdb.base/close-deleted-bfd-solib.so: No such file or directory
> sig=10, sig@entry=<error reading variable: Can't read data for section '.eh_frame' in file '.../gdb/testsuite/gdb.base/close-deleted-bfd-solib.so'>) at ../sysdeps/unix/sysv/linux/raise.c:55
> 55        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) PASS: gdb.base/close-deleted-bfd.exp: continue
> bt
> #0  0x0000003424e348c7 in __GI_raise (sig=10) at ../sysdeps/unix/sysv/linux/raise.c:55
> (gdb) FAIL: gdb.base/close-deleted-bfd.exp: bt
>
> ->
>
> continue
> Continuing.
> Program received signal SIGUSR1, User defined signal 1.
> 0x0000003424e348c7 in __GI_raise (sig=10) at ../sysdeps/unix/sysv/linux/raise.c:55
> 55        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) PASS: gdb.base/close-deleted-bfd.exp: continue
> bt
> #0  0x0000003424e348c7 in __GI_raise (sig=10) at ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x00007ffff7dd36ee in foo () at ./gdb.base/close-deleted-bfd-lib.c:21
> #2  0x000000000040071c in main () at ./gdb.base/close-deleted-bfd-main.c:31
> (gdb) PASS: gdb.base/close-deleted-bfd.exp: bt
>
> ------------------------------------------------------------------------------
>
> The bfd_cache_close_all() calls are there since:
>         commit ce7d45220e4ed342d4a77fcd2f312e85e1100971
>         Author: Jerome Guitton <guitton@adacore.com>
>         Date:   Fri Jul 30 12:05:45 2004 +0000
>         Message-ID: <20040730130834.GA3855@act-europe.fr>
>         Date: Fri, 30 Jul 2004 15:08:34 +0200
>         https://sourceware.org/ml/gdb-patches/2004-05/msg00678.html
>         https://sourceware.org/ml/gdb-patches/2004-06/msg00008.html
>         https://sourceware.org/ml/gdb-patches/2004-07/msg00439.html
>
> While I do not know how to fix it on MS-Windows at least Linux systems do not
> need to be diadvantaged by the MS-Windows problem workaround.
>
> I have no idea if the used #ifdefs match the host systems needing this
> workaround from 2004.
>
> Additionally I believe such patch is useful for performance reasons.
>
> No regressions on {x86_64,x86_64-m32,i686}-fedora23pre-linux-gnu.
>
>
> Thanks,
> Jan
>
> gdb/ChangeLog
> 2015-02-16  Jan Kratochvil  <jan.kratochvil@redhat.com>
>
>         * corefile.c (reopen_exec_file): Wrap bfd_cache_close_all call into
>         MS-Windows conditional.
>         * exec.c (exec_file_attach): Likewise.
>         * symfile.c (symbol_file_add_with_addrs): Likewise.

Hi.  The comments in the code for the call to bfd_cache_close_all
explain the windows situation well enough, but IIUC it is necessary
to *not* call bfd_cache_close_all here on linux, but there are no
comments in the code explaining this.
Can you add something?  Thanks.

E.g., something like

  /* It is necessary to not call bfd_cache_close_all here on
     linux because ... */

Also, IIUC there's a fragileness here that we still need to address.
AFAICT there's nothing in the bfd cache API that prevents bfd
from randomly closing the file in the future, and yet from reading
the bug report it is necessary that we do not close the file.

E.g., does gdb need to keep open, for example, every shared library
used by the inferior?
Perhaps a better way to go would be to teach gdb to handle
the file going way.