Re: How to find EXC_BAD_ACCESS bug?

FROM : Steve Sims
DATE : Sun Aug 29 00:27:29 2004

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 (<email_removed>) 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 | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.