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?
Well, I got into something but it will require more research.
The above code is
0x0040223a e8ed360100 call solver.find (0041592c)
0x0040223f 8945f0 mov dword ptr [path],eax
0x00402242 83c40c add esp,0c
0x00402245 85c0 test eax,eax
0x00402247 7408 je D main+00000241 (00402251)
0x00402249 8b45f0 mov eax,dword ptr [path]
0x0040224c 8b08 mov ecx,dword ptr [eax]
0x0040224e ff5138 call dword ptr [ecx+38]
0x00402251 ff3564e14400 push dword ptr
[__xt_z+000000f4 (0044e164)]
0x00402257 ff3560e14400 push dword ptr
[__xt_z+000000f0 (0044e160)]
0x0040225d 837df000 cmp dword ptr [path],00
0x00402261 0f95c0 setne al
0x00402264 e86b8d0000 call
std.stdio.writefln!(string, bool).writefln (0040afd4)
After find() gets called, eax = 0x0030f900 which points to
nowhere valid.
Hence, ecx will contain a null address and [ecx + 38] as vtable
lookup points to 0x00000038, which lands in no man's land and
boom.
Trying to get deep into this will require a bit more time.
I wonder if this is caused by the nodes being stored into a
BinaryHeap with an Array store, coupled with a RedBlackTree as
well. Maybe some interaction between the manual memory management
and the GC.
More info later on.
--
Paulo
