Garbage collector collects live objects

[Ruslan Mullakhmetov via Digitalmars-d-learn]

On Tuesday, 9 December 2014 at 16:53:02 UTC, Steven Schveighoffer
wrote:
> On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
>> On Tue, 09 Dec 2014 14:52:53 +0000
>> Ruslan Mullakhmetov via Digitalmars-d-learn
>> <digitalmars-d-learn at puremagic.com> wrote:
>>
>>> On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven 
>>> Schveighoffer
>>> wrote:
>>>> On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I experience very strange problem: GC somehow collects live
>>>>> objects.
>>>>>
>>>>> I found it because i got segfaults. After debugging and
>>>>> tracing i found
>>>>> this is because of accessing not allocated memory.
>>>>>
>>>>> I did the following checks:
>>>>>
>>>>> - added to some class invariant check for access to 
>>>>> suspicious
>>>>> members
>>>>> with assertion
>>>>>
>>>>> assert(GC.addrOf(cast(void*)x) !is null);
>>>>>
>>>>>
>>>>> where it fails DETERMINISTICALLY at some point
>>>>>
>>>>> - printing address of allocated classes where i observe the
>>>>> following
>>>>> pattern
>>>>>
>>>>> -> ctor
>>>>>      check
>>>>>      check
>>>>>      check
>>>>> <- dtor
>>>>>      check (fails)
>>>>>
>>>>> could anybody advice me with something? I got really
>>>>> frustrated by this
>>>>> strange behaviour which i can not fix right now.
>>>>>
>>>>> key observations:
>>>>> - it is deterministically behaviour (what gets me even more
>>>>> confused
>>>>> cause GC collections as far as i know runs from time to 
>>>>> time)
>>>>> - i do not play with pointers optimisation like hiding its 
>>>>> in
>>>>> ints or
>>>>> floats.
>>>>> - i operate with large uniformly distributed (video) data in
>>>>> memory
>>>>> where pointer like patterns may occur. but this is not the
>>>>> case cause
>>>>> (1) it brings at worst long living objects (2) input 
>>>>> sequence
>>>>> constant
>>>>> but allocated pointers each run different.
>>>>>
>>>>
>>>> A random guess, since you haven't posted any code, are you
>>>> accessing GC resources inside a destructor? If so, that is 
>>>> not
>>>> guaranteed to work. A class destructor, or a destructor of a
>>>> struct that is contained inside a class, can only be used to
>>>> destroy NON-GC resources.
>>>>
>>>> If you want more help, you need to post some code. Something
>>>> that minimally causes the issue would be good.
>>>>
>>>> -Steve
>>>
>>> No, there is no accessing GC resources in dtors.
>>>
>>> the only usage of dtor in one class is
>>>
>>> 	~this()
>>> 	{
>>> 		_file.close();
>>> 	}
>>>
>>> where _file is of type std.file.File
>>>
>>> i'll try to extract problem to any observable source code but 
>>> all
>>> my previous attempts lead to problem being diminish.
>>
>> that file can be already finalized. please remember that 
>> `~this()` is
>> more a finalizer than destructor, and it's called on *dead* 
>> object.
>> here this means that any other object in your object (including
>> structs) can be already finalized at the time GC decides to 
>> call your
>> finalizer.
>
> File is specially designed (although it's not perfect) to be 
> able to close in the GC. Its ref-counted payload is placed on 
> the C heap to allow access during finalization.
>
> That being said, you actually don't need to write the above in 
> the class finalizer, _file's destructor will automatically be 
> called.
>
>> just avoid "destructors" unless you *really* need that. in 
>> your case
>> simply let GC finalize your File, don't try to help GC. this 
>> is not C++
>> (or any other language without GC) and "destructors" aren't 
>> destructing
>> anything at all. "destructors" must clean up the things that 
>> GC cannot
>> (malloc()'ed memory, for example), and nothing else.
>>
>
> Good advice ;)
>
> I would say other than library writers, nobody should ever 
> write a class dtor.
>
> -Steve


thanks, I got it: either C++ or D dtors are minefield =)

but i still have no clue how to overcome GC =(