• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: gdb behaviour..
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gdb behaviour..


  • Subject: Re: gdb behaviour..
  • From: Paul Forgey <email@hidden>
  • Date: Tue, 2 May 2006 15:02:03 -0700

I have similar problems with gdb too. I brought it up on this list over a year ago nobody believed me. I can never reproduce it with test code which makes it impossible for me to submit good bug reports about it. I've been told to make sure I'm not accidentally mixing components from different versions of X-Code and it works fine for them. Good for them. I sympathize with the OP but I'm glad it isn't just me. It happens on ALL of our machines with CLEAN installations. It's very, very frustrating. I can't tell you how much time we spend fighting the damn debugger when trying to port our code to this platform.

I make heavy use of the following C++ features which seem to aggravate the problem:
- RTTI
- templates
- namespaces
- shared libraries


Objective C++ code importing classes from this code will show the same problems too.

Has nothing to do with threads. Some of my code is multi threaded but it happens in single threaded code too. The "continue" behavior is not because gdb is going to another thread. It seems to happen when it doesn't believe there is symbol information where there should be. e.g. stepping into "printf" or some other function that doesn't have debug info will correctly result in "step over" behavior instead. But if you try to "step into" a symbol that gdb is confused about, it will instead act like "continue".

Other problems include breakpoints working about half the time when specifying a symbol name rather than a file and line. Valid symbols that gdb can resolve and locate, not mis-typed or unresolved after loading shared libraries or mis-overloaded C++ functions.

Quite often gdb will also abort with internal assertions, leaving you screwed after finally getting your program to reproduce that not often seen bug.

Gdb on Linux is much worse for sure, but it still very broken on OS-X/ Darwin.

On May 2, 2006, at 9:19 AM, Fons Rademakers wrote:

No, single thread.

Cheers, Fons.



David Dunham wrote:
On 2 May 2006, at 06:26, Fons Rademakers wrote:
I've a lot of problems with stepping through my code as often a click on "Step Over" results in the same behaviour as "Continue",
Is your code threaded?
David Dunham A Sharp, LLC
Voice/Fax: 206 783 7404 http://a-sharp.com
"People seem to misinterpret complexity as sophistication" -- Niklaus Wirth
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40cern.ch This email sent to email@hidden

--
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: gdb behaviour..
      • From: Jan Hegewald <email@hidden>
    • Re: gdb behaviour..
      • From: Fons Rademakers <email@hidden>
    • Re: gdb behaviour..
      • From: Jason Bobier <email@hidden>
References: 
 >gdb behaviour.. (From: Fons Rademakers <email@hidden>)
 >Re: gdb behaviour.. (From: David Dunham <email@hidden>)
 >Re: gdb behaviour.. (From: Fons Rademakers <email@hidden>)

  • Prev by Date: Re: Linker can't find symbol _environ in Framework
  • Next by Date: Re: gdb behaviour..
  • Previous by thread: Re: gdb behaviour..
  • Next by thread: Re: gdb behaviour..
  • Index(es):
    • Date
    • Thread