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