From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30459 invoked by alias); 17 Feb 2015 07:45:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30411 invoked by uid 89); 17 Feb 2015 07:45:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 17 Feb 2015 07:45:00 +0000 Received: by mail-ob0-f175.google.com with SMTP id va2so50550817obc.6 for ; Mon, 16 Feb 2015 23:44:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7aqNqI0EFz41HHmEBAKoTG2y5DhoUkvHm2YPQLsEVnY=; b=d/bfIvO4GpBn76OtCAmHAoA0emJuuxB2m2Z6Zd1tppqMPA0xfALuodLsVVTTWroEYF DTW16NiOBABWoKe6BmVun6s51zcNDyILO39kfx/J6fGDQOV3BgmrWOpKK6rzpij+MxMx Km6Sym35aFEXD8mnaBVwSxGL663n9siKTOq2rJfu8qoljzHRS+O0Qqx+hzgoSqu2/I6G pxgY2K206HIYrGE0BCpA3o7KoKb7r878IX7zfoaELqOypFFiYAG63wWLR8zXAXY/cYBC iQh5SH7mZcqmNwy4MBO09QBFOVX2aGe3alayfshXdY5c6mzmvMa/WSHmWrTnhziw/W2M atXw== X-Gm-Message-State: ALoCoQmPhB5/iAgTIDphZCEKGJfaZfqFofQ7D56b4ny/jxAjzTU5ZB17hpkpghR9OWTLKwWfKYHW MIME-Version: 1.0 X-Received: by 10.182.214.1 with SMTP id nw1mr17972368obc.21.1424159098487; Mon, 16 Feb 2015 23:44:58 -0800 (PST) Received: by 10.182.142.226 with HTTP; Mon, 16 Feb 2015 23:44:58 -0800 (PST) In-Reply-To: <20150216210958.GA9701@host1.jankratochvil.net> References: <20150216210958.GA9701@host1.jankratochvil.net> Date: Tue, 17 Feb 2015 07:45:00 -0000 Message-ID: Subject: Re: [patch] Do not close BFDs, breaking deleted inferior shlibs From: Doug Evans To: Jan Kratochvil Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00384.txt.bz2 On Mon, Feb 16, 2015 at 1:09 PM, Jan Kratochvil 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 > #include > 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=) 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 > 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 > > * 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.