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