On Tuesday, 8 November 2016 at 07:39:12 UTC, Era Scarecrow wrote:
> 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...

One of the reasons it is not specified is that very often the hierarchy is not a simple tree, but a graph with possibly many cycles. As a matter of fact, very often child nodes have pointers to parent nodes, so that what is logically a tree is practically a graph with lots of cycles. So it is not possible to identify a root object which does not have incoming dead pointers, and no guarantee can be provided.

On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote:
> Imagine a resource wrapper like so:
>
> class Foo
> {
>    int *mem;
>    this() { mem = cast(int *)malloc(int.sizeof); }
>    ~this() { .free(mem); }
> }
>
> Now, you have a problem if you do something like this:
>
> class Bar
> {
>    Foo foo;
>    ~this() { delete foo; }
> }
>

Is there a valid use case for something like this? Why would you want to do anything inside ~this with GC memory?

On Tuesday, 8 November 2016 at 11:26:55 UTC, bachmeier wrote:
>
> Is there a valid use case for something like this? Why would you want to do anything inside ~this with GC memory?

 If we assume it's a C++ attachment/library/object using different memory allocation?

On Tuesday, 8 November 2016 at 11:53:37 UTC, Era Scarecrow wrote:
> On Tuesday, 8 November 2016 at 11:26:55 UTC, bachmeier wrote:
>>
>> Is there a valid use case for something like this? Why would you want to do anything inside ~this with GC memory?
>
>  If we assume it's a C++ attachment/library/object using different memory allocation?

I'm not sure what "it's" is referring to in your statement. In the example, Foo wraps manually allocated memory that is freed when Foo goes out of scope. If the goal is to free the memory in Foo when Bar goes out of scope, that can be done without error by rewriting Foo. Therefore I'm not understanding how this situation can arise in real world code (I'm sure it can, though, which is why I'm asking).

On 11/8/16 6:26 AM, bachmeier wrote:
> On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote:
>> Imagine a resource wrapper like so:
>>
>> class Foo
>> {
>>    int *mem;
>>    this() { mem = cast(int *)malloc(int.sizeof); }
>>    ~this() { .free(mem); }
>> }
>>
>> Now, you have a problem if you do something like this:
>>
>> class Bar
>> {
>>    Foo foo;
>>    ~this() { delete foo; }
>> }
>>
>
> Is there a valid use case for something like this? Why would you want to
> do anything inside ~this with GC memory?

Indeed, you should not. I'm saying this type of error can explain the observed behavior.

The original post I responded to said "I don't know if the double free problem is related to this."

-Steve

On Tuesday, 8 November 2016 at 14:55:53 UTC, Steven Schveighoffer wrote:

> Indeed, you should not. I'm saying this type of error can explain the observed behavior.
>
> The original post I responded to said "I don't know if the double free problem is related to this."
>
> -Steve

Okay. I thought maybe there was a gotcha that I wasn't aware of.