From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2219 invoked by alias); 19 Nov 2002 21:39:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2166 invoked from network); 19 Nov 2002 21:39:29 -0000 Received: from unknown (HELO entoo.connect.com.au) (192.189.54.8) by sources.redhat.com with SMTP; 19 Nov 2002 21:39:29 -0000 Received: from dragon.home (acc1-ppp79.cam.dialup.connect.net.au [210.10.230.79]) by entoo.connect.com.au (Postfix) with ESMTP id DD5AB9C6EF for ; Wed, 20 Nov 2002 08:31:15 +1100 (EST) Subject: gdb 5.2.1-4, gcc 3.2-7 and lyx thread problem From: Ben Stanley To: gdb@sources.redhat.com Content-Type: text/plain Organization: University of Wollongong Message-Id: <1037741969.25407.32.camel@dragon.home> Mime-Version: 1.0 Date: Tue, 19 Nov 2002 13:39:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00232.txt.bz2 Hi, I was trying to use gdb on lyx-1.3.0cvs. I would place a breakpoint in the lyx code (Counter::reset) and run until the program hit the breakpoint. When that happened, gdb went crazy: (gdb) run [New Thread 8192 (LWP 26110)] Unknown token, keepLyXAspectRatio, skipping. Unknown token, keepLyXAspectRatio, skipping. [New Cannot find thread 16385: invalid thread handle This LyX was built with the Qt front end, and I'm told by the LyX developers that only a single thread is used. I then tried to find out what's going on with the threads: (gdb) info threads * 1 Thread 8192 (LWP 26128) [No stack.] lyx: SIGHUP signal caught Segmentation fault The segmentation fault was actually gdb, not lyx (reported by ddd). Thus gdb is becoming internally corrupted when I use it on LyX. I'm wondering if upgrading gdb to the latest cvs version might help here. I'm currently using the version that comes with RH-8.0. LyX uses lots of advanced C++. I also have a problem with the following: (gdb) list Counters::reset [0] cancel [1] all [2] Counters::reset(std::string const&) at counters.C:174 [3] Counters::reset() at counters.C:164 That output is correct. However, trying to set a breakpoint is wrong: (gdb) break 'Counters::reset' [0] cancel [1] all [2] Counters::reset(std::string const&) at /usr/include/c++/3.2/bits/basic_string.h:229 [3] Counters::reset() at /usr/include/c++/3.2/bits/stl_tree.h:651 This gives incorrect information on the source location of these functions. Quoted and unquoted versions of each command give the same answers. Thanks for any help. Ben. -- Ben Stanley, PhD candidate School of Information Technology and Computer Science University of Wollongong