View mode: basic / threaded / horizontal-split · Log in · Help
March 10, 2008
Explicit memory deallocation
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
March 10, 2008
Re: Explicit memory deallocation
"Julian Schick" <julianschick@gmx.net> wrote:
> 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

"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 =)
March 10, 2008
Re: Explicit memory deallocation
> "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.
March 10, 2008
Re: Explicit memory deallocation
"Neil Vice" <psgdg@swiftdsl.com.au> wrote in message 
news:fr3k2v$30ss$1@digitalmars.com...

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

The current GC implementation that D uses (no matter what library you're 
using) is synchronous, that is, it does not run in a separate thread.  GC 
collections will only happen on memory allocations.  When the GC is 
disabled, it should not perform any collections.
March 10, 2008
Re: Explicit memory deallocation
Jarrett Billingsley schrieb:
> "Neil Vice" <psgdg@swiftdsl.com.au> wrote in message 
> news:fr3k2v$30ss$1@digitalmars.com...
> 
>> "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...
> 
> The current GC implementation that D uses (no matter what library you're 
> using) is synchronous, that is, it does not run in a separate thread.  GC 
> collections will only happen on memory allocations.  When the GC is 
> disabled, it should not perform any collections. 
> 
> 

(tango user)
the GC disable disables collection runs as already said.
That means, if there is no more memory, new memory is requested from the 
OS. In the normal case, the GC would first do the collection to try to 
get the needed memory. Everything else should work like befor.

Explicit calls to "delete" should work as usual.
March 11, 2008
Re: Explicit memory deallocation
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
March 11, 2008
Re: Explicit memory deallocation (nitpick)
Unknown W. Brackets wrote:
> Lastly, if none of that helps, checking if you're using auto for
> automatic freeing.

Being a bit nitpicky, but auto is for pure type inference. Scope is for automatic freeing :)

It was changed a while back.

--downs
March 11, 2008
Re: Explicit memory deallocation (nitpick)
== Quote from downs (default_357-line@yahoo.de)'s article
> Unknown W. Brackets wrote:
> > Lastly, if none of that helps, checking if you're using auto for
> > automatic freeing.
> Being a bit nitpicky, but auto is for pure type inference. Scope is for automatic freeing :)
> It was changed a while back.

Unfortunately, both still work.


Sean
March 11, 2008
Re: Explicit memory deallocation (nitpick)
Sean Kelly wrote:
> == Quote from downs (default_357-line@yahoo.de)'s article
>> Unknown W. Brackets wrote:
>>> Lastly, if none of that helps, checking if you're using auto for
>>> automatic freeing.
>> Being a bit nitpicky, but auto is for pure type inference. Scope is for automatic freeing :)
>> It was changed a while back.
> 
> Unfortunately, both still work.

I think that's only true for the case where it is part of the class 
definition.   As in:

   scope class Foo {...}

For that, yes, auto class Foo{...}  still works and means the same thing.

But that's the only case in which scope and auto are still 
interchangeable, right?

Still I would have thought 'auto class' would have been removed at least 
in the D2 branch.  But I just tried it out and it's still there.

--bb
March 11, 2008
Re: Explicit memory deallocation (nitpick)
"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message 
news:fr6mbu$1pvd$1@digitalmars.com...

> I think that's only true for the case where it is part of the class 
> definition.   As in:
>
>    scope class Foo {...}
>

Actually the class doesn't even have to be "scope" and the distinction is a 
bit weirder.

auto f = new Foo();

will not make it scoped, and just performs type inference.

auto Foo f = new Foo();

_is_ scoped.  Why?  I don't know.  Left in there?  Intentional?  fuh.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home