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/[email protected])
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.
--
Paulo
