How to find EXC_BAD_ACCESS bug?
-
My Cocoa app regularly crashes with this bad access error, but every
time I debug the app it (appears to) crash in a different place. Often
this is buried way down in system routines, where the debugger shows
only disassembled op codes. Sometimes this is purely in the NSApp's run
loop, so there is none of my code on the stack. Sometimes it's in my
code, but there's no obviously suspect code nearby.
What are the basic tools/procedures for using Xcode to narrow this down?
Andrew
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 17, 2004, at 3:13 PM, Andrew Duncan wrote:
> My Cocoa app regularly crashes with this bad access error, but every
> time I debug the app it (appears to) crash in a different place. Often
> this is buried way down in system routines, where the debugger shows
> only disassembled op codes. Sometimes this is purely in the NSApp's
> run loop, so there is none of my code on the stack. Sometimes it's in
> my code, but there's no obviously suspect code nearby.
>
> What are the basic tools/procedures for using Xcode to narrow this
> down?
Run your app with NSZombiesEnabled turned on. This kind of problem is
almost always the result of over-releasing an object.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 17, 2004, at 4:13 PM, Andrew Duncan wrote:
> My Cocoa app regularly crashes with this bad access error, but every
> time I debug the app it (appears to) crash in a different place. Often
> this is buried way down in system routines, where the debugger shows
> only disassembled op codes. Sometimes this is purely in the NSApp's
> run loop, so there is none of my code on the stack. Sometimes it's in
> my code, but there's no obviously suspect code nearby.
>
> What are the basic tools/procedures for using Xcode to narrow this
> down?
Can you give us some backtraces of these crashes?
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 17 Aug, 2004, at 15:39, John C. Randolph wrote:
> On Aug 17, 2004, at 3:13 PM, Andrew Duncan wrote:
>
>> My Cocoa app regularly crashes with this bad access error,[...]
>
> Run your app with NSZombiesEnabled turned on. This kind of problem is
> almost always the result of over-releasing an object.
Thanks John, is this a preprocessor define?
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 17 Aug, 2004, at 15:44, Nick Zitzmann wrote:
> On Aug 17, 2004, at 4:13 PM, Andrew Duncan wrote:
>
>> My Cocoa app regularly crashes with this bad access error,[...]
>> What are the basic tools/procedures for using Xcode to narrow this
>> down?
>
> Can you give us some backtraces of these crashes?
Thanks Nick; at this point I think the backtraces are just too
different each time to really help. (I may be wrong about this though.)
But on a related note, the debugger log suggests
Try setting environment variable MallocHelp to see tools to help debug
So what environment is it talking about?
Andrew
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 17, 2004, at 5:03 PM, Andrew Duncan wrote:
> Thanks Nick; at this point I think the backtraces are just too
> different each time to really help. (I may be wrong about this
> though.)
>
> But on a related note, the debugger log suggests
>
> Try setting environment variable MallocHelp to see tools to help
> debug
>
> So what environment is it talking about?
Your application probably has a memory problem somewhere. If it's
crashing in NSPopAutoreleasePool(), that means the application
deallocated an object that was in the autorelease pool. If you're
seeing console errors about double-free() calls, that means exactly
what it says. If it's crashing in objc_msgSend(), that means a message
was sent to an object that was deallocated at some point. Backtraces in
this case can be more important than you may think...
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18 Aug 2004, at 01:03, Andrew Duncan wrote:
> On 17 Aug, 2004, at 15:44, Nick Zitzmann wrote:NSZombieEnabled is also an environment variable. An easy way to set
>> On Aug 17, 2004, at 4:13 PM, Andrew Duncan wrote:
>>
>>> My Cocoa app regularly crashes with this bad access error,[...]
>>> What are the basic tools/procedures for using Xcode to narrow this
>>> down?
>>
>> Can you give us some backtraces of these crashes?
>
> Thanks Nick; at this point I think the backtraces are just too
> different each time to really help. (I may be wrong about this
> though.)
>
> But on a related note, the debugger log suggests
>
> Try setting environment variable MallocHelp to see tools to help
> debug
>
> So what environment is it talking about?
>
these is in the arguments tab of the info window for your executable
(in Xcode).
Fred
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 17, 2004, at 3:59 PM, Andrew Duncan wrote:
> On 17 Aug, 2004, at 15:39, John C. Randolph wrote:
>> On Aug 17, 2004, at 3:13 PM, Andrew Duncan wrote:
>>
>>> My Cocoa app regularly crashes with this bad access error,[...]
>>
>> Run your app with NSZombiesEnabled turned on. This kind of problem
>> is almost always the result of over-releasing an object.
>
> Thanks John, is this a preprocessor define?
No, it's an environment variable. Set it in the executable inspector
in XCode.
Actually, that should be "NSZombieEnabled".
For details, see "NSDebug.h".
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On mercredi, ao{t 18, 2004, at 12:13 AM, Andrew Duncan wrote:
> My Cocoa app regularly crashes with this bad access error, but every
> time I debug the app it (appears to) crash in a different place. Often
> this is buried way down in system routines, where the debugger shows
> only disassembled op codes. Sometimes this is purely in the NSApp's
> run loop, so there is none of my code on the stack. Sometimes it's in
> my code, but there's no obviously suspect code nearby.
>
> What are the basic tools/procedures for using Xcode to narrow this
> down?
Enable NSZombie.
You're probably releasing too much.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>>> Run your app with NSZombiesEnabled turned on. This kind of problem
>>> is almost always the result of over-releasing an object.
>>
>> Thanks John, is this a preprocessor define?
>
> No, it's an environment variable. Set it in the executable inspector
> in XCode.
>
> Actually, that should be "NSZombieEnabled".
>
> For details, see "NSDebug.h".
Thanks for the pointer. Now, do I define NSZombieEnabled as 1, or YES,
or just anything at all? FWIW, I tried 1, and didn't see any new info
in the run log...
Andrew
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 18, 2004, at 2:35 PM, Andrew Duncan wrote:
>>>> Run your app with NSZombiesEnabled turned on. This kind of problem
>>>> is almost always the result of over-releasing an object.
>>>
>>> Thanks John, is this a preprocessor define?
>>
>> No, it's an environment variable. Set it in the executable inspector
>> in XCode.
>>
>> Actually, that should be "NSZombieEnabled".
>>
>> For details, see "NSDebug.h".
>
> Thanks for the pointer. Now, do I define NSZombieEnabled as 1, or YES,
> or just anything at all? FWIW, I tried 1, and didn't see any new info
> in the run log...
Set it to YES.
It won't log anything until/unless you send a message to a freed object.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> Thanks for the pointer. Now, do I define NSZombieEnabled as 1, or
>> YES, or just anything at all? FWIW, I tried 1, and didn't see any new
>> info in the run log...
>
> Set it to YES.
Aha! Very helpful indeed. This should be an FAQ somewhere, methinks...
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18 Aug 2004, at 18:38, John C. Randolph wrote:
>>> No, it's an environment variable. Set it in the executable
>>> inspector in XCode.
>>>
>>> Actually, that should be "NSZombieEnabled".
>>>
>>> For details, see "NSDebug.h".
>>
>> Thanks for the pointer. Now, do I define NSZombieEnabled as 1, or
>> YES, or just anything at all? FWIW, I tried 1, and didn't see any new
>> info in the run log...
>
> Set it to YES.
>
> It won't log anything until/unless you send a message to a freed
> object.
I'm facing a similar problem right now - I'm getting an EXC_BAD_ACCESS
exception in my app at semi-random times.
I tried setting NSZombieEnabled, (double clicked on my executable in
the XCode Groups & Files list and added NSZombieEnabled as an
environment variable set to yes) but I'm not seeing any additional
messages logged anywhere that I can see. Nothing in the GDB console,
the system console, or anywhere I can think of. Is there some magic
place that Zombie messages should be appearing?
Right now I can only make guesses as to exactly what's going on. The
logical route I have right now to working out what could be causing
this is to insert a whole big stack of debug logging. Any other
suggestions would most definitely be appreciated.
Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Steve Sims (<steve_sims...>) on Mon, Aug 23, 2004 21:25 said:
> I'm facing a similar problem right now - I'm getting an EXC_BAD_ACCESS
> exception in my app at semi-random times.
You might try the various malloc environment variables:
<http://developer.apple.com/releasenotes/DeveloperTools/MallocOptions.html>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 23, 2004, at 7:25 PM, Steve Sims wrote:
> I tried setting NSZombieEnabled, (double clicked on my executable in
> the XCode Groups & Files list and added NSZombieEnabled as an
> environment variable set to yes) but I'm not seeing any additional
> messages logged anywhere that I can see. Nothing in the GDB console,
> the system console, or anywhere I can think of. Is there some magic
> place that Zombie messages should be appearing?
You need to enable NSZombieEnabled by setting a boolean value inside
the program while the program is running, preferably before
NSApplicationMain() is called, not in an environmental variable. See
NSDebug.h inside Foundation for details.
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Nick Zitzmann (<nick...>) on Mon, Aug 23, 2004 22:13 said:
> You need to enable NSZombieEnabled by setting a boolean value inside
> the program while the program is running, preferably before
> NSApplicationMain() is called, not in an environmental variable.
Either way works, I just tried.
In fact, I have been reading about/testing NSZombie stuff recently, and
decided to make a simple test app illustrating its use. Feel free to
take a look:
<http://www.cam.org/~cwatson/>
The biggest problems I had were:
- be sure to set variables to YES/NO, not 1/0
- NSZombie does not help with toll-free bridged classes
- NSHangOnMallocError is apparently broken
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Thanks for the suggestion Sean and for making your NSZombie test app
available.
By using your example I have made sure that I'm enabling zombies
correctly within my app. From what I can tell it seems that I'm not
creating any zombie objects. I do, however, definitely have some kind
of malloc problem.
I have done a great deal of searching around today to try to establish
the cause of my EXC_BAD_ACCESS bug. The exception that I get is
inconsistent - it never seems to happen in the same place. Usually
though it is occurring somewhere deep within Quartz.
Often I will see a malloc error before my app crashes, reporting an
incorrect checksum for a freed object. If I use malloc_history to find
references to that block I often find that it was allocated and
deallocated within Quartz routines, however it is occasionally from
something completely different. This information though does not seem
very relevant...
It seems fairly clear to me that I have a memory corruption problem.
Somehow, somewhere, I'm asking for a chunk (or several chunks) of
memory and then overrunning those memory blocks.
How I'm managing to do that though is a bit of a mystery to me. I'm
fairly certain I allocate memory correctly everywhere I use it.
MallocDebug isn't providing me with any useful information since it
doesn't keep information after an application crash. GDB has allowed
me to verify that my data is intact, or at least seems to be, at the
time of crashes, but that hasn't helped me get any closer to working
out what the bug is.
I'm at a bit of a loss right now as to how to track this bug down
further. Any suggestions would be most gratefully received.
Steve
On 24 Aug 2004, at 02:20, Sean McBride wrote:
> Either way works, I just tried._______________________________________________
>
> In fact, I have been reading about/testing NSZombie stuff recently, and
> decided to make a simple test app illustrating its use. Feel free to
> take a look:
> <http://www.cam.org/~cwatson/>
>
> The biggest problems I had were:
> - be sure to set variables to YES/NO, not 1/0
> - NSZombie does not help with toll-free bridged classes
> - NSHangOnMallocError is apparently broken
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 24, 2004, at 6:06 PM, Steve Sims wrote:
> I have done a great deal of searching around today to try to establish<snip>
> the cause of my EXC_BAD_ACCESS bug. The exception that I get is
> inconsistent - it never seems to happen in the same place. Usually
> though it is occurring somewhere deep within Quartz.
> It seems fairly clear to me that I have a memory corruption problem.
Have you considered the possibility of bad RAM? It would explain the
random and unpredictable nature of your memory problems.
--
eric
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Steve Sims (<steve_sims...>) on Tue, Aug 24, 2004 19:06 said:
> Often I will see a malloc error before my app crashes, reporting an
> incorrect checksum for a freed object.
Have you tried breaking there, breakpoint on malloc_printf()?
> I'm at a bit of a loss right now as to how to track this bug down
> further. Any suggestions would be most gratefully received.
Well, I once spent a month or so trying to find a bug that sounds like
yours and here are some of the things I'd suggest, in no order:
- Use everything in NSDebug.h, not just NSZombieEnabled
- use all the malloc env vars, especially set MallocCheckHeapEach to 1
- for C++ new/delete try CodeWarrior's DebugNew (NB its not thread safe)
- try a different IDE/compiler to rule out bugs there
- try different Macs, RAM, OS versions to rule out bugs there
- fix all memory leaks (see MallocDebug, 'leaks' command line tool)
- try malloc_history
- try Apple's guard malloc, or any of the other replacement malloc
implementations.
- use debug variants of Apple's frameworks (easiest by setting
DYLD_IMAGE_SUFFIX env var to _debug)
- rip out code and use process of elimination :(
(My particular bug was nasty, I couldn't use all the debugging facilities
fully, like MallocCheckHeapEach=1, because it was code that interfaced
with hardware, and if I slowed it down too much nothing worked at all.
It also took about 5 hours to repro the bug! :( In the end I had to rip
out code until it went away... in the end, it was a QuickTime bug, fixed
in 10.3. One month down the drain. But I learned a lot about debugging.
hehe)
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Hi Sean,
Sorry for the slight delay in the reply - I was out of town for a few
days.
On 25 Aug 2004, at 22:58, Sean McBride wrote:
> Steve Sims (<steve_sims...>) on Tue, Aug 24, 2004 19:06 said:
>> Often I will see a malloc error before my app crashes, reporting an
>> incorrect checksum for a freed object.
> Have you tried breaking there, breakpoint on malloc_printf()?
I think I had turned on just about all the malloc debugging options, so
I was getting breaks.
>> I'm at a bit of a loss right now as to how to track this bug down
>> further. Any suggestions would be most gratefully received.
>
> Well, I once spent a month or so trying to find a bug that sounds like
> yours and here are some of the things I'd suggest, in no order:
>
> - Use everything in NSDebug.h, not just NSZombieEnabled
> - use all the malloc env vars, especially set MallocCheckHeapEach to 1
> - for C++ new/delete try CodeWarrior's DebugNew (NB its not thread
> safe)
> - try a different IDE/compiler to rule out bugs there
> - try different Macs, RAM, OS versions to rule out bugs there
> - fix all memory leaks (see MallocDebug, 'leaks' command line tool)
> - try malloc_history
> - try Apple's guard malloc, or any of the other replacement malloc
> implementations.
> - use debug variants of Apple's frameworks (easiest by setting
> DYLD_IMAGE_SUFFIX env var to _debug)
> - rip out code and use process of elimination :(
Thanks for the advice.
I had indeed turned on just about all the NSDebug features, as well as
the malloc env vars. I even went as far as using
MallocCheckHeapEach=1. When I used malloc_history I discovered that
the data block(s) being reported as corrupt was allocated and used not
by my own code but by code deep within the Quartz rendering system. I
was at a loss as to what I was doing wrong, since the beziers I was
throwing at Quartz were, according to my investigations with GDB, all
still intact with no corruption and had not been deallocated.
Eventually I did the last thing you suggest, and ripped out code. The
first thing I removed was a call within my display routine that
incrementally added a clipping bezier to the current graphics context.
As if by magic the exception disappeared.
It would seem therefore that there may be a limitation within Quartz as
to the number of clipping paths you can add to a context, and that if
you exceed this limit you'll get memory corruption. I'm not sure
exactly how many clipping paths there were, but I'd guess I had
typically added about 20 when the crash occurred. It is, however, not
entirely consistent and may also be related to free memory - I don't
have much RAM.
I came up with a suitable work-around and now all is well.
Thanks again,
Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Steve Sims (<steve_sims...>) on Sat, Aug 28, 2004 18:27 said:
> Eventually I did the last thing you suggest, and ripped out code. The
> first thing I removed was a call within my display routine that
> incrementally added a clipping bezier to the current graphics context.
> As if by magic the exception disappeared.
You ripped things out in the right order. :)
> It would seem therefore that there may be a limitation within Quartz as
> to the number of clipping paths you can add to a context, and that if
> you exceed this limit you'll get memory corruption. I'm not sure
> exactly how many clipping paths there were, but I'd guess I had
> typically added about 20 when the crash occurred. It is, however, not
> entirely consistent and may also be related to free memory - I don't
> have much RAM.
You could check with the quartz list:
<http://lists.apple.com/mailman/listinfo/quartz-dev>
Maybe you have found an OS bug that Apple would like to know about...
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
