From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5631 invoked by alias); 10 Nov 2007 01:27:15 -0000 Received: (qmail 5620 invoked by uid 22791); 10 Nov 2007 01:27:14 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 Nov 2007 01:27:12 +0000 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id lAA1RA0N018633 for ; Fri, 9 Nov 2007 17:27:10 -0800 Received: from nf-out-0910.google.com (nfdk4.prod.google.com [10.48.137.4]) by zps77.corp.google.com with ESMTP id lAA1R8Mn027116 for ; Fri, 9 Nov 2007 17:27:09 -0800 Received: by nf-out-0910.google.com with SMTP id k4so865854nfd for ; Fri, 09 Nov 2007 17:27:08 -0800 (PST) Received: by 10.67.115.2 with SMTP id s2mr104780ugm.1194658016802; Fri, 09 Nov 2007 17:26:56 -0800 (PST) Received: by 10.67.21.14 with HTTP; Fri, 9 Nov 2007 17:26:56 -0800 (PST) Message-ID: Date: Sat, 10 Nov 2007 01:27:00 -0000 From: "Douglas Evans" To: gdb@sourceware.org Subject: Re: linux-thread-db.c not only caller of add_thread, -> gdb segv In-Reply-To: <20071109140225.GA32113@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071109140225.GA32113@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00076.txt.bz2 On Nov 9, 2007 6:02 AM, Daniel Jacobowitz wrote: > This is true. But if you're using the Linux native target, and reach > the point where any of the other add_thread calls are made, then > there's already a bug. It is supposed to detect all new threads. > It sort of has to - that's how infrun gets the new ptid_t. Ah, thanks. I understand the threading support a bit better now. [for completeness' sake, target = x86_64-linux] > 3) Figure out how you got to any of the other add_thread calls. Or that. :-) I think I understand what's going on. Consider a threaded app that first exec's itself (e.g. because it wants to be run with a specific value for LD_LIBRARY_PATH, the actual reason doesn't matter though). GDB doesn't properly handle the fact that the original process is gone. GDB detects the exec and removes thread_db_ops from the target stack. But (a) it doesn't clear out thread_list and (b) still thinks it has control of the running process. By the time GDB gets to handle_inferior_event() case TARGET_WAITKIND_EXECD it has added the new process to thread_list with the call to add_thread in infrun.c, and thus there's an entry in thread_list with "private" == NULL. thread_list also has stale entries at this point. If the user does a ^c after the exec and then "info threads" gdb will detect an internal error due to the stale entries in thread_list and crash. But if instead the user does a ^c and then "sharedlib some_library" GDB will push thread_db_ops back on the target stack. If the user then does "continue" thread_db_resume gets called and boom, segv because thread->private == NULL in clear_lwpid_callback. I'm working on a patch but I don't know this part of GDB very well. [small test case available, I'll include it with the patch]