Re: debuging help (on Windows)

[Sheldon Gill]

Lloyd Dupont wrote:
> > Lloyd Dupont wrote:
> > [snip...]
> >
> > 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....

Ah!  Then you need to instrument your managed C++ code. It is handling the 
Objective-C invocations from C# right?

Looking alright and actually being alright are two different things ;)

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

Ah. I'd need to see the code to be of more help here. I'd guess you've a 
pointer handling problem in the binding. An invalid memory access here would 
seem to me that you're calling p with an invalid reference.

I'd look at your C# object and Objective-C objects being out of synch.

> 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 (:-(

What fcode sharing do you think should be in place?

> I complained a few times about that already...

Complaining won't get you far. Put up a considered proposal. Put forward code. 
Then it can be discussed and progressed if there is a consensus.

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

I don't see why this is a limitation. You can attach gdb to your running 
application and debug away from there.

Alternatively, you may want to extend the debug support in SharpDevelop.

> Thanks for your tips Sheldon!

You're welcome.


Regards,
Sheldon