Likely closure memory corruption
deadalnix
deadalnix at gmail.com
Sun Mar 3 18:10:11 PST 2013
On Sunday, 3 March 2013 at 17:27:52 UTC, Maxim Fomin wrote:
> On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
>> auto objectSource = new FileSource("../libs/object.d");
>> auto object = lex!((line, index, length) {
>> import std.stdio;
>> writeln("new location 2 ! ", cast(void*) objectSource);
>>
>> return Location(objectSource, line, index, length);
>> })(objectSource.content);
>>
>> Running this, I see that at some point, objectSource is
>> changed. The output is
>> new location 2 ! 7F494EEC1D40
>> new location 2 ! 7F494EEC1D40
>> ...
>> new location 2 ! 7F494EEC1D40
>> new location 2 ! 7F494EEC2EA0
>>
>> 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 ?
>
> It is unlikely that the particular closure corrupts data since
> at three times the address is correct. Closure bugs are
> typically revealed as wrong function code, so there would no
> difference between addresses. Something else in scope of
> "objectSource" may corrupt it. You can try to pass explicitly
> types of closure parameters, rewrite closure as a nested
> function - it used to mitigate some closure bugs in the past.
> Without compilable source I cannot say anything more.
The problem here is that the codebase involved is rather huge. Do
you have an advice to reduce the issue ?
More information about the Digitalmars-d
mailing list