discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debuging help (on Windows)


From: Lloyd Dupont
Subject: Re: debuging help (on Windows)
Date: Thu, 2 Feb 2006 12:49:11 +1000

Lloyd Dupont wrote:
[snip...]
That won't help. You want

defaults write NSGlobalDomain GSZombieEnabled YES
I'll try that!


       OR

set GSZombieEnabled=YES

What can I do?

There are a number of things which you can do:

First, is your non-GNUstep code entirely .NET? Otherwise memory debugging for this would help. It could be this code is trashing GNUstep memory.
Yep it is!
(except for a ManagedC++ module (which manage GNUstep binding)) but even after checking many time, it still looks allright....




Second, Unit testing should exercise your code vigourously and may help identify the cause or at least narrow it.

Mhh... there is a problem here.
a pseudo code like that
NSAutoreleasePool  *p = [[NSAutoreleasePool alloc] init];
[[NMFIleIO loadFile: @"aFileName"] autorelease];
[p release];

work well on the command line but crash (invalid memory access) on p.Relase() in .NET.
The problem is LoadFile is huge.....
It looks like a bug in my binding but, heck, I looked again and again unsucesfuly so it's why I would like some tool help, or a way to get extra information (such as the Zombie stuff)...


Third, I've always found DesignByContract very helpful. Assert everything, everywhere as far as possible.

A bit difficult, the ObjectiveC code is huge, is not mine, and we have no fcode sharing solution in place (:-(
I complained a few times about that already...

Fourth, look at NSDebug.h for more GNUstep memory debugging capabilities.

Is there any debugging tool (even commercial) I could use?

GDB may help. You might like to use Insight as a front-end.

GDB doesn't help because command line, ObjectiveC test seems to work fine.

Regards,
Sheldon
Thanks for your tips Sheldon!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]