Re: GDB crashing
Re: GDB crashing
- Subject: Re: GDB crashing
- From: Jim Ingham <email@hidden>
- Date: Mon, 16 Apr 2007 11:18:52 -0700
On Apr 15, 2007, at 7:09 AM, Ed Martin wrote:
I guess i need to explain a bit more, i really just wanted to know
if it is considered "normal" and acceptable for gdb to exit on an
assert() (in gdb itself) when debugging a program, i was under the
impression that no matter how bad your application is gdb should not
crash and should instead stop the program or print a message when
gdb can no longer control it (because of something like a messed up
stack), or at least something close
From the replies i got so far i would guess that it is normal for
gdb to hit this assert() when debugging an application and it is not
considered a bug in gdb, is that correct?
gdb shouldn't be hitting this assert even if your program has died a
horrible death. It means that some part of the system higher up isn't
figuring out that the program is in a bad state, and so it asks a
lower level part of the system to do something that doesn't make sense.
If you have a example that you can send us that shows this happening,
please file a bug with the example and the Xcode-gdb log, plus
anything you had to do in the program to reproduce the session. Even
if you can't send us the example, please file a bug with the Xcode-gdb
log. We may or may not be able to figure out what went wrong without
the example, but it's worth a shot.
To get this log on Tiger, quit Xcode and in Terminal do:
defaults write com.apple.Xcode PBXGDBDebuggerLogToFile YES
defaults write com.apple.Xcode PBXGDBDebuggerLogFileName /tmp/
XCGDBLog.txt
Then start up Xcode and run the session, and then send us /tmp/
XCGDBLog.txt.
You can then use:
defaults delete com.apple.Xcode PBXGDBDebuggerLogToFile
etc.
to stop producing the log.
Jim
@Philip Aker
In my application i needed an arbitrary number of rows and
columns (my largest test case is actually a 1000x1000 table), so i
can't do a switch, instead i decided to set kColFirst = 'A\0\0\0'
and add/subtract that to the property ID, so i can pass it through
the Apple stuff as a valid ID (it would give me the largest span of
"valid" IDs), and later pass it through my stuff by using that as an
offset
Philip Aker wrote:
On 2007-04-14, at 21:13:41, Ed Martin wrote:
the actual line in my source code is the property >= kColFirst,
the crash happens when i click "Step Over" and the application
goes to this line
if (property >= kColFirst){
this is happening inside an Item-data callback for the DataBrowser
Just guessing -- we really need to see code -- but one thing to be
aware of with DataBrowser is that Apple reserves column values less
than 1024.
I believe that most Mac folks would naturally use a switch on
legitimate FourCharCode values in DB callbacks:
In header
enum {
kColFirst = 'Frst',
};
In callback:
switch( property ) {
case( kColFirst ): {
// do stuff
break;
}
Philip Aker
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
_______________________________________________
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