On Fri, 11 Apr 2014 07:25:15 -0400, Paulo Pinto <pjmlp@progtools.org> wrote:

> On Friday, 11 April 2014 at 09:32:29 UTC, Chris wrote:
>> On Friday, 11 April 2014 at 06:51:01 UTC, Paulo Pinto wrote:
>>> On Thursday, 10 April 2014 at 09:31:30 UTC, John Colvin wrote:
>>>> On Thursday, 10 April 2014 at 09:24:51 UTC, Paulo Pinto wrote:
>>>>> In a toy project I am working on with D v2.065, I came to the following situation:
>>>>>
>>>>> Node path = solver.find (map, start, end);
>>>>> if (path !is null) {
>>>>>  path.writeContents();  <-- Access Violation
>>>>> }
>>>>>
>>>>> Apparently between the test and trying to use the class, the reference becomes null.
>>>>>
>>>>> Quite strange in a single threaded application.
>>>>>
>>>>> Any idea what might be happening or should I delve into assembly?
>>>>>
>>>>> --
>>>>> Paulo
>>>>
>>>> Delve delve delve. Is this in an optimised build?
>>>
>>> I found out the cause, apparently std.container.Array destroys the memory used by reference types as well (e.g. classes).
>>>
>>> The small example below reproduces the error.
>>>
>>> Apparently the way Array manages the memory on its own invalidates the reference pointed by node, as I assume bad == node, but its memory is invalid.
>>>
>>> import std.stdio;
>>> import std.container;
>>>
>>>
>>> class Node {
>>> }
>>>
>>> Node indentity (Node n)
>>> {
>>>    return n;
>>> }
>>>
>>> Node badIndentity (Node n)
>>> {
>>>    Array!Node data;
>>>    data.insert(n);
>>>    return data.front();
>>> }
>>>
>>> int  main(string[] args)
>>> {
>>>    auto node = new Node();
>>>    auto n = indentity (node);
>>>    writefln("Hello the address is %s", n);
>>>    auto bad = badIndentity (node);
>>>    writefln("Hello the address is %s", bad);
>>>
>>>    return 0;
>>> }
>>
>> This reminds me of the question I had about the use of appender. (http://forum.dlang.org/thread/xfnvtlzyolmtncsmmqqi@forum.dlang.org)
>>
>> The internal memory management of containers and appender can be the source of subtle bugs. For cases like your badIndentity function, Objective-C has autorelease, so it's only released when the program is done with the value.
>> Out of interest, why would you write a function like badIndentity this way? Or is it just a proof of concept?
>
>
> This was only to show you how to reproduce the error.
>
> On my application I use Array as a backing store for a BinaryHeap used to store the nodes that are available on the A* open list.
>
> If this usage of Array is correct and the destroy method is misbehaving, I can create a bug for it.
>
> I assume Array should manage its own memory but not touch the memory that belongs to reference types stored on it. At least the documentation doesn't say otherwise.

This is a side effect of classes being first-class reference types. Array needs to call destroy on structs, but not on classes. Sort of a "shallow destroy."

It's an interesting bug.

-Steve

On Friday, 11 April 2014 at 12:26:14 UTC, Steven Schveighoffer wrote:
> This is a side effect of classes being first-class reference types. Array needs to call destroy on structs, but not on classes. Sort of a "shallow destroy."
>
> It's an interesting bug.
>
> -Steve

Yeah, the issue "transcends" the language. Things like "FieldTypeTuple" on a class (directly) also tell you what the class is made of.

Ideally, the call should have been "protected" by a "hasElaborateDestructor" to begin with. Not only does it make the code faster for types that don't have destructors, "hasElaborateDestructor" replies false for classes.

User @denis-sh had complained about "destroy" before for this very reason, and had proposed a "destruct":
https://github.com/D-Programming-Language/phobos/pull/929

On Freitag, 11. April 2014 13:44, monarch_dodra wrote:

> Yes, it's bug. Trivial to fix too. Please file it.

I think I already filed it quite some time ago: https://issues.dlang.org/show_bug.cgi?id=6998

See also: http://stackoverflow.com/questions/22624021

On Friday, 11 April 2014 at 12:52:52 UTC, Nils Boßung wrote:
> On Freitag, 11. April 2014 13:44, monarch_dodra wrote:
>
>> Yes, it's bug. Trivial to fix too. Please file it.
>
> I think I already filed it quite some time ago:
> https://issues.dlang.org/show_bug.cgi?id=6998

I am appalled that such a trivial bug, one that leads to undefined behavior, could be left open for so long :/

No one to blame I guess, but... damn.

On Friday, 11 April 2014 at 13:02:01 UTC, monarch_dodra wrote:
> On Friday, 11 April 2014 at 12:52:52 UTC, Nils Boßung wrote:
>> On Freitag, 11. April 2014 13:44, monarch_dodra wrote:
>>
>>> Yes, it's bug. Trivial to fix too. Please file it.
>>
>> I think I already filed it quite some time ago:
>> https://issues.dlang.org/show_bug.cgi?id=6998
>
> I am appalled that such a trivial bug, one that leads to undefined behavior, could be left open for so long :/
>
> No one to blame I guess, but... damn.

No need to create duplicate entries then :)