Re: MallocDebug: Can it be used at all?
Re: MallocDebug: Can it be used at all?
- Subject: Re: MallocDebug: Can it be used at all?
- From: Eric Peyton <email@hidden>
- Date: Thu, 14 Mar 2002 15:59:46 -0600
The other thing you can try is to use the malloc command line
envirnoment variables with the leaks tool to help you find problems as
well
[spawn:/System/Library/Filesystems] [epeyton] setenv MallocHelp
[spawn:/System/Library/Filesystems] [epeyton] ls
malloc[366]: environment variables that can be set for debug:
- MallocGuardEdges to add 2 guard pages for each large block
- MallocDoNotProtectPrelude to disable protection (when previous flag
set)
- MallocDoNotProtectPostlude to disable protection (when previous flag
set)
- MallocStackLogging to record all stacks. Tools like leaks can then be
applied
- MallocStackLoggingNoCompact to record all stacks. Needed for
malloc_history
- MallocScribble to detect writing on free blocks: 0x55 is written upon
free
- MallocCheckHeapStart <n> to check the heap from time to time after <n>
operations
- MallocHelp - this help!
To see the leaks the best way ...
>setenv MallocStackLogging
> run your program from the command line here
In another terminal window, run the command line tool "leaks" and
"malloc_history" and give it the pid of the application.
Eric
On Thursday, March 14, 2002, at 03:47 PM, Christopher Holland wrote:
Actually, I'm seeing the same thing here. I haven't messed with it much
yet, so I can't even guess at a cause, though I can tell you that I
don't have any of the Unsanity products installed, so that is probably
not the cause (at least for me).
FYI, I have installed the following: TinkerTool, USBOverdrive, &
Diablotin...although, I don't think any of those should cause any
problems (save maybe TinkerTool). I figure that this might help sort
out any commonalities between people who have the problems.
If I get around to fixing it, I'll let you know if I figure out
anything.
Christopher
On Thursday, March 14, 2002, at 01:38 PM, Matthew Formica wrote:
I don't think I've ever seen MallocDebug lie. In this case, I bet
your app
is interacting in a weird way with Unsanity products (WindowShade/X,
etc.) -
try disabling them.
- Matthew
On 3/14/02 8:32 AM, "Timothy Ritchey" <email@hidden>
wrote:
On Thursday, March 14, 2002, at 09:23 AM, Jonathan Feinberg wrote:
When I try to launch the built app with MallocDebug, I almost
immediately get a dialog stating that "Target application crashed:
/path/to/my/app accessed memory at 0x7c0802ae illegally."
If it is any consolation, I am seeing this as well. I assumed that I
wasn't doing something right, like linking with
libMallocDebug.A.dylib,
or setting the -force_flat_namespace option that is suggested for
running a program separately from the MallocDebug application and
connecting to it. I couldn't even get my app to compile using
-force_flat_namespace.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.