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