Re: debuging help (on Windows)

[Lloyd Dupont]

> 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 ;)
I know but... if it looks alright, that mean I can't find the fault!


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

Haaa!!......

I wonder now if it could be that if I call Release explicitely, when object 
get disposed by .NET, Release is called a second time....
(I mean in my finalization code I explicitely call release and set an 
internal handle to null, whereas the auto-generated MC++ code for Release 
call [obj release] but doesn't dismiss the internal handle)...
I might have it....
It certainly looks suspicious...
Thanks for this brainstorm ;-)

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

Sorry, I already disccussed extensiveley about that with my boss.
our "GNUstep.NET" binding is doomed to stay closed source for now.
(Not that I think everything should be OpenSourced, but I think this work 
would gain from it).

> > 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 meand code sharing.
In fact I think I should take the opportunity that my boss is away this week 
to install Subversion on his computer...
(which is vaguely planned at the bottom of our TODO list after this and that 
and anything that could popup in between)
(Or would you advise me to use CVS? I have been told subversion is more 
flexible, particularly if I change my mind regarding folder hierarchy/ 
filenames)

> > > 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.
Hoho...
could I do that?
I have to try!
I think I had some other problem with GDB like meaningless function name and 
stuff (in the C part of the code, regardless of the .NET layer)
Apparently the libraries used by GNUstep (and GNUstep itself) is missing 
debugging information or something.

> Alternatively, you may want to extend the debug support in SharpDevelop.
Well, oh... I don't know.. maybe not immediately... ;-)