From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7072 invoked by alias); 23 Nov 2002 06:13:47 -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 7025 invoked from network); 23 Nov 2002 06:13:47 -0000 Received: from unknown (HELO entoo.connect.com.au) (192.189.54.8) by sources.redhat.com with SMTP; 23 Nov 2002 06:13:47 -0000 Received: from dragon.home (acc1-ppp248.cam.dialup.connect.net.au [210.10.230.248]) by entoo.connect.com.au (Postfix) with ESMTP id A7D6457C43 for ; Sat, 23 Nov 2002 17:05:30 +1100 (EST) Subject: Re: gdb 5.2.90-cvs, gcc 3.2-7 and lyx thread problem From: Ben Stanley To: gdb mailing list Content-Type: text/plain Organization: University of Wollongong Message-Id: <1038032029.14018.1.camel@dragon.home> Mime-Version: 1.0 Date: Fri, 22 Nov 2002 22:13:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00334.txt.bz2 I have now upgraded my gdb to current cvs. Version string is GNU gdb 5.2.90_2002-11-22-cvs The problems I previously reported remain unchanged. I have been performing tests using gdb directly on RH 8.0. I also tried running lyx under gdb under gdb. At the point where the instance of gdb debugging lyx crashes, the state is: (gdb) info threads * 1 Thread 8192 (LWP 12396) [No stack.] Program received signal SIGSEGV, Segmentation fault. 0x0809e3f6 in get_next_frame (frame=0x0) at blockframe.c:287 287 return frame->next; (top-gdb) where #0 0x0809e3f6 in get_next_frame (frame=0x0) at blockframe.c:287 #1 0x080d356d in find_relative_frame (frame=0x0, level_offset_ptr=0xbfffef6c) at stack.c:1608 #2 0x080d4517 in info_threads_command (arg=0x0, from_tty=1) at thread.c:471 #3 0x0808bfde in do_cfunc (c=0x0, args=0x0, from_tty=1) at cli/cli-decode.c:53 #4 0x0808d8ea in cmd_func (cmd=0x83b7838, args=0x0, from_tty=1) at cli/cli-decode.c:1523 #5 0x0811110e in execute_command (p=0x83a865c "", from_tty=1) at top.c:711 #6 0x080d5eb9 in command_handler (command=0x83a8650 "info threads") at event-top.c:504 #7 0x080d62d8 in command_line_handler (rl=0x860dd38 "info threads") at event-top.c:799 Examining the value of selected_frame reveals that it is 0x0 when find_relative_frame is called by info_threads_command. This is about as far as I can go without learning the internals of gdb myself. I'd really like to be able to use gdb on lyx. As it stands currently, gdb is of almost no use. I noticed that when I start LyX, it gave the message: (gdb) run Starting program: /share/install/linux/extras/lyx/lyx-current-doc/lyx-devel/src/lyx [New Thread 8192 (LWP 12521)] but when it hits a breakpoint, I get [New Cannot find thread 16385: invalid thread handle (gdb) How can the thread number change? Of course its invalid - there are not other new threads created (that gdb reports). What variable can I set a watchpoint on so that I can find out when the 'current thread' changes? Ben. On Wed, 2002-11-20 at 08:39, Ben Stanley wrote: > 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 > -- Ben Stanley, PhD candidate School of Information Technology and Computer Science University of Wollongong