Likely closure memory corruption

deadalnix deadalnix at gmail.com
Fri Mar 8 08:25:52 PST 2013


On Thursday, 7 March 2013 at 04:21:01 UTC, deadalnix wrote:
> On Monday, 4 March 2013 at 14:21:11 UTC, deadalnix wrote:
>> On Monday, 4 March 2013 at 10:55:58 UTC, Don wrote:
>>> On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
>>> ...
>>>> Obviously, the program segfault soon after that.
>>>>
>>>> It sounds like some memory corruption occurs under the hood. 
>>>> What can I do to work around that bug and to help solving it 
>>>> ?
>>>
>>> Have you compiled this with the latest gitHEAD ? Several very 
>>> nasty wrong-code bugs were fixed very recently (eg, bug 9568).
>>
>> No luck. I just tested it and it doesn't work.
>
> I did some investigation yesterday. It seems that the frame 
> pointer that is passed when calling the closure is not always 
> the right one.
>
> I now can catch the problem as soon as it occurs. I'll try to 
> reduce it to a simpler test case, but it seems really difficult.

Sooooooo,

I have a struct. The struct have a context pointer. I have this 
method :

@property
auto save() inout {
	return inout(Lexer)(t, r.save, line, index);
}

The context pointer IS NOT COPIED.

Fixed it that way :

@property
auto save() inout {
	// XXX: dmd bug, context pointer isn't copied properly
	// doing it manualy using black magic.
	// Context pointer is the last element of the struct. Here in 
position 9.
	auto ret = inout(Lexer)(t, r.save, line, index);
	(cast(void**) &ret)[9] = (cast(void**) &this)[9];
	
	return ret;
}

Very scary that I have to do that kind of things.


More information about the Digitalmars-d mailing list