From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20651 invoked by alias); 18 Aug 2008 14:15:33 -0000 Received: (qmail 20636 invoked by uid 22791); 18 Aug 2008 14:15:31 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 14:14:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id m7IEEaat230998 for ; Mon, 18 Aug 2008 14:14:36 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7IEEZZi1036396 for ; Mon, 18 Aug 2008 16:14:35 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7IEEZNJ010283 for ; Mon, 18 Aug 2008 16:14:35 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m7IEEZtO010275; Mon, 18 Aug 2008 16:14:35 +0200 Message-Id: <200808181414.m7IEEZtO010275@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 18 Aug 2008 16:14:35 +0200 Subject: Re: [rfc] Fix removing breakpoint from shared library race To: brobecker@adacore.com (Joel Brobecker) Date: Mon, 18 Aug 2008 14:15:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080818114617.GH16894@adacore.com> from "Joel Brobecker" at Aug 18, 2008 03:46:17 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2008-08/txt/msg00484.txt.bz2 Joel Brobecker wrote: > > When *removing* breakpoints, however, there is no such check. I have a > > multi-threaded test case that reproducibly runs into an error when trying > > to remove a breakpoint from a shared library that was *just* unloaded. > [...] > > Am I missing some reason why we shouldn't get to this point? Otherwise, > > this seems a reasonble solution to me ... > > The fix looks reasonable to me, but I'm not sure, though. Perhaps > part of the problem is that I don't see how you got there in your > example (I'm having trouble figuring out a case where the debugger > would end up removing a breakpoint while a shared library has just > been unloaded). Could you post more details? The actual test case was using the Cell multi-arch debugger. However, I think the problem can potentially also show up in current GDB with multi-threaded code. Assume you have a thread A that is just unloading a shared library 1.) app calls dlclose 2.) dlclose unmaps shared library 3.) dlclose calls _dl_debug_event (which GDB has a breakpoint on) 4.) GDB gets active 5.) GDB processes the unload event while at the same time, thread B is doing something that invokes GDB A.) app runs into a breakpoint B.) GDB gets active C.) GDB stops all threads D.) GDB removes all breakpoints E.) GDB goes to user prompt (Note that this still assumes all-stop, breakpoints-not-always-inserted mode. If those new modes are active, the race would probably be more difficult to trigger.) Now imagine the race where thread A is just in-between steps 2.) and 3.) while thread B runs into the breakpoint (which causes GDB to stop thread A at this point). When GDB now performs action D.), the breakpoints that were inserted into the shared library are still on GDB's list as active, because step 5.) which would have set them to solib_disabled state did not yet run. However, attempting to remove the breakpoint will fail because the library was already unmapped. This is the situation that my patch attempts to address, by having the remove_breakpoints not fail. At some later point, either when GDB actually gets to process the solib event, or when GDB tries to re-insert the breakpoints, GDB will properly recognize that the library has been unloaded and sets the state to solib_disabled. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com