how to debug memory errors

Era Scarecrow via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon Nov 7 23:39:12 PST 2016


On Tuesday, 8 November 2016 at 06:04:59 UTC, thedeemon wrote:
> On Tuesday, 8 November 2016 at 05:36:22 UTC, Era Scarecrow 
> wrote:
>
>>  Hmmm.. I had the impression that if something was referenced 
>> by another object, then it couldn't be collected,
>
> Another *live* object, I.e. reachable from globals and stack. 
> If you have a big tree and it becomes unreachable (you only had 
> a pointer to its root and you nulled it), then this whole tree 
> becomes garbage, and its nodes and leafs will be collected in 
> unpredictable order, with destructors being run in 
> unpredictable order, even when these dead nodes reference each 
> other.

  And I can't help but hope it would start at the largest/base 
object and work it's way up. Or the largest object and then work 
it's way down. Alright...

  Shouldn't for warnings then in the destructor about accessing 
arrays, class objects or other allocated items that they might 
not even exist anymore?

  If I think of it like making a class/struct that does 
compression and the blob that manages tracking the compressed 
data uses simple array appending, and then the struct or class 
notices it's thrown away and it has an active connection to save 
it's contents to a file, as part of the destructor I'd probably 
write it so it would save and flush what data was left before 
deallocating everything or closing the file descriptors. With 
this you might have to manage your own memory to ensure the GC 
doesn't accidentally remove important data first...


More information about the Digitalmars-d-learn mailing list