Explicit memory deallocation

[Unknown W. Brackets]

It's important to remember that calling a function can't remove compiled 
code.  The compiler is by no means detecting that you are calling 
std.gc.disable(), so it must compile in calls to the gc even if they are 
being ignored.

The easiest way to check on the gc is probably to trace destructor 
calls.  IIRC (I may be wrong), it calls those synchronously with freeing 
the memory, so if you have one called twice on the same reference you 
know the problem.

I know you mentioned it happens when a constructor is called, but it 
could simply be that the gc freeing something twice is horribly 
destroying something inside the gc that is still happening...

Lastly, if none of that helps, checking if you're using auto for 
automatic freeing.  This isn't the gc, technically I think, so I'm 
pretty sure it will still automatically free when it falls off the stack 
even if the gc is disabled.

Sorry, I'm about to go to bed and we've got DST here in the states, so I 
feel I haven't organized my post as best I should have...

-[Unknown]


Julian Schick wrote:
> I'm currently working with D 1.0 and experiencing really strange
> access violations.
> 
> I have deactivated the GC using "std.gc.disable()" and free the memory
> by myself. For a few days now, there have been occured those access violations.
> 
> The strange things about it:
> - the access violations occur at completely different lines in the code
> - the access violations occur often when a constructor is called
> (I was tracing, and the debug message before the constructor call appeared, and the one i placed as first command IN the constructor never
> appeared, so there's evidently a problem with allocating memory)
> - when I debug the application, i find names like this in the assembly next to the point where the application stopped: _D3gcx2GC6gcLockC9ClassInfo
> _D3gcx2GC12setFinalizerMFPvPFPvPvZvZv+00000094
> -> Is the garbage collector still active??? (gcLock ???)
> - If I remove a "delete" statement which I would say is absolutely "safe"
> because it deletes an object from which I know that there is only one
> reference to. And this reference will run out of scope just behind the "delete" statement. Well, if I remove this statement, there are no more
> access violations. That is only an example, I have a lot of other "delete"
> statements in my code and I don't know what happens if I remove
>  them as well.
> 
> I suppose, regarding these facts, that the GC is still running.
> Am I not correctly disabling the GC?
> If it is running, can't I free memory explicitely without disturbing the gc?
> Are there any issues known which could be the reason for my problem?
> 
> Greetings
> Julian Schick