Julian Schick Wrote:

> > "disable() temporarily disables garbage collection cycle, enable() then reenables them."
> > 
> > Given this I suspect that the GC still expects to be in control of memory so even though the GC thread may not be running dynamically freeing things, constructor calls will still register pointers with the GC and expect some sort of internal consistency you are breaking with explicit destroys perhaps...
> > 
> > Having said that, are the variables you're destroying "scope" at all (including "in" parameters)? If so then my understanding was that independantly of the GC thread these would be freed automatically when they go out of scope, resulting in them being destroyed twice if destroyed explicitly perhaps.
> > 
> > Evidently I'm no expert but hopefully I've given you some ideas =)
> 
> OK, I see, well, that's what I supposed, too.
> Then the question is how I can switch off the GC entirely.
> That should solve all my problems :-)
> 
> Maybe there's also somebody out there, who can confirm
> that it is not possible to use GC and explicit freeing the same time.
> Because I tend to not believing that.

I had a bug in one of my apps which looked the same. For further debugging try to set the reference to null, after you explicitly delete it. The problem in my app was, that it pointed to already freed memory and the GC seemed to run, although deactivated, and finally trying to free this chunk.

best regards
Matthias Walter

On Wed, 12 Mar 2008 09:23:55 +0200, Matthias Walter <walter@mail.math.uni-magdeburg.de> wrote:

> Julian Schick Wrote:
>
>> > "disable() temporarily disables garbage collection cycle, enable() then
>> > reenables them."
>> >
>> > Given this I suspect that the GC still expects to be in control of memory so even though the GC thread may not be running dynamically freeing things, constructor calls will still register pointers with the GC and expect some sort of internal consistency you are breaking with explicit destroys perhaps...
>> >
>> > Having said that, are the variables you're destroying "scope" at all (including "in" parameters)? If so then my understanding was that independantly of the GC thread these would be freed automatically when they go out of scope, resulting in them being destroyed twice if destroyed explicitly perhaps.
>> >
>> > Evidently I'm no expert but hopefully I've given you some ideas =)
>>
>> OK, I see, well, that's what I supposed, too.
>> Then the question is how I can switch off the GC entirely.
>> That should solve all my problems :-)
>>
>> Maybe there's also somebody out there, who can confirm
>> that it is not possible to use GC and explicit freeing the same time.
>> Because I tend to not believing that.
>
> I had a bug in one of my apps which looked the same. For further debugging try to set the reference to null, after you explicitly delete it. The problem in my app was, that it pointed to already freed memory and the GC seemed to run, although deactivated, and finally trying to free this chunk.

This doesn't make much sense... can you reproduce the issue?

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com