From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10231 invoked by alias); 27 Jul 2009 00:02:19 -0000 Received: (qmail 9824 invoked by uid 22791); 27 Jul 2009 00:02:18 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f198.google.com (HELO mail-qy0-f198.google.com) (209.85.221.198) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jul 2009 00:02:12 +0000 Received: by qyk36 with SMTP id 36so3649558qyk.12 for ; Sun, 26 Jul 2009 17:02:10 -0700 (PDT) Received: by 10.224.45.75 with SMTP id d11mr5387558qaf.358.1248652930283; Sun, 26 Jul 2009 17:02:10 -0700 (PDT) Received: from hydrogen.gmail.com (207-172-203-39.c3-0.upd-ubr7.trpr-upd.pa.cable.rcn.com [207.172.203.39]) by mx.google.com with ESMTPS id 5sm8012293qwg.25.2009.07.26.17.02.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Jul 2009 17:02:09 -0700 (PDT) Date: Mon, 27 Jul 2009 00:02:00 -0000 Message-ID: <877hxvro1r.wl%naesten@gmail.com> From: Samuel Bronson To: Mathieu Lacage Cc: gdb@sourceware.org Subject: Re: random gdb errors: corruption of nptl_db event buffers ? In-Reply-To: <74fef6df0907251005y1c02246ay9b6b1bd7e7c326d3@mail.gmail.com> References: <74fef6df0907251005y1c02246ay9b6b1bd7e7c326d3@mail.gmail.com> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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: 2009-07/txt/msg00209.txt.bz2 At Sat, 25 Jul 2009 19:05:45 +0200, Mathieu Lacage wrote: > > hi, > > I am trying to debug some random errors I get from gdb while debugging > my program. No, the bug is not in gdb, it's in the inferior process > but it appears that the inferior process is confusing ntpl_db beyond > repair. It would be really nice if one could make GDB pretend it has no clue about threads for situations like this where it only gets confused... I had such an issue trying to debug something that happened in DOSEMU's signal handlers which only happened when they were called from DPMI code, which had a completely different ES or FS (whichever it is that threads in Linux use to keep track of what thread is running) from what libthread_db was expecting. As a consequence, I believe GDB was refusing to even acknowledge that the inferior had stopped -- something to do with an error() call before it took note of that in the proper data structure, I think it was? (The error itself turned out to have the same cause, actually: I had built dosemu for profiling, and the instrumentation functions called from the signal handler were failing because of the very same register having an unexpected value.)