[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objective-C gdb (was: Re: Problem with AppKit/Fonts?)

From: Eric Dahlman
Subject: Re: Objective-C gdb (was: Re: Problem with AppKit/Fonts?)
Date: Mon, 14 Jul 2003 10:48:46 -0500

On Monday, July 14, 2003, at 10:21 AM, Richard Frith-Macdonald wrote:

On Sunday, July 13, 2003, at 05:41 AM, Adam Fedor wrote:

On Saturday, July 12, 2003, at 07:58 AM, David Ayers wrote:

Richard Frith-Macdonald wrote:

I use gdb on ix86 machines ... and I have no problem with the 'next' command. Perhaps what's needed is a short test program to run the debugger on, and
an explanation of how to reproduce the problem with 'next'

I havn't been able to reproduce this with "simple" -base tests, but with ProjectCenter.

I "break" at main, "next" all the way to NSApplicationMain, step into it and when trying to 'next' over the creation of the autorelease pool, gdb continues (i.e. dosen't stop when the creation returns). Note that in main there is already a release pool created and destroyed before calling NSApplicationMain.

I get it now. It only seems to happen when using next within a method that is in a shared library. In fact, I've been able to replicate this on even C programs (see attached). Someone should tell me I'm wrong - I can't believe no one else has noticed this...

I think it must be a relatively recent change ... it doesn't show up superficially on tests of recent copies of the debugger, and mostly I've been using older copies. My main development systems are using gdb built from cvs with your patches on the 7th of March, and the problem
does not show up in your test application with that version of gdb.

Just for historical reference I remember back when I was using DDD (as a front end to gdb) on Solaris around the turn of the century (Gee that makes me sound like a geezer) there was a similar problem where if you were stepping through code and returned form a function call in a library it would act like a cont(inue). At the time I found out that this was a deficiency in GDB at the time (possibly related to elf...?) so I would usually set a breakpoint after the function call that was causing me the problem to get control again.

Now I looked for a google reference but I didn't get lucky although I did find some traffic on the NetBSD lists about a similar problem circa 98. I guess my point is that it is not surprising and it is not without precedent; make sure you have the newest GDB and report it as a bug if it happens.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]