From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25438 invoked by alias); 1 Sep 2006 00:14:29 -0000 Received: (qmail 25430 invoked by uid 22791); 1 Sep 2006 00:14:28 -0000 X-Spam-Check-By: sourceware.org Received: from rgminet01.oracle.com (HELO rgminet01.oracle.com) (148.87.113.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Sep 2006 00:14:27 +0000 Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7VMDpH8002754; Thu, 31 Aug 2006 18:13:46 -0600 Received: from dhcp-4op13-4op14-west-130-35-182-230.us.oracle.com by rcsmt250.oracle.com with ESMTP id 1916641091157069584; Thu, 31 Aug 2006 18:13:04 -0600 Message-ID: <44F77934.3000305@oracle.com> Date: Fri, 01 Sep 2006 00:14:00 -0000 From: Chuck Simmons User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: bartoschek@or.uni-bonn.de, drow@false.org, gdb@sourceware.org Subject: Re: Cannot fetch general-purpose registers for thread 1342445920: generic error Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00000.txt.bz2 Historically, in my experience, GDB has rarely handled threads well. (There was a year or two about 10 to 15 years ago where things worked fairly well, but since then...) Here is a short session on Suse Linux using Posix threads: " (gdb) run 44123:127.0.0.1 dsk log.3382 Starting program: /home/csimmons/src/sysmon/sysmon2 44123:127.0.0.1 dsk log.3382 [Thread debugging using libthread_db enabled] [New Thread 1075110560 (LWP 31423)] main: policy=2, prio=1 [New Thread 1077214128 (LWP 31426)] ping_cpu: policy=2, prio=1 [New Thread 1079315376 (LWP 31427)] Couldn't get registers: No such process. " This is probably a timing related bug in the implementation of GDB. When debugging programs that spawn threads using back to back gdb sessions, some runs will allow one to do debugging, and some runs won't. Cs