Likely closure memory corruption

[Maxim Fomin]

On Monday, 4 March 2013 at 02:10:12 UTC, deadalnix wrote:
> 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 ?

No specific advice except for dropping everything except 
FileSource definition and lex template. By the way, what is 
objectSource.content? A tuple of line, index, length?