Re: debuging help (on Windows)

[Lloyd Dupont]

> 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!