<div class="gmail_extra"><div class="gmail_quote">2012/12/20 H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Thu, Dec 20, 2012 at 05:45:51AM +0100, deadalnix wrote:<br>
> On Thursday, 20 December 2012 at 04:15:31 UTC, H. S. Teoh wrote:<br>
> >On Thu, Dec 20, 2012 at 04:37:25AM +0100, deadalnix wrote:<br>
> >>Can you tell more about what is the corruption ?<br>
> >><br>
> >>Are you getting garbage elements from front ? Can you use a debugger<br>
> >>or add some writeln to show some pointer addresses ?<br>
> ><br>
> >Yeah it's garbage elements from front. I'll try a debugger, but this<br>
> >problem only happens in git dmd, not in gdc, and dmd executables are<br>
> >a bit of a pain to deal with in gdb.<br>
> ><br>
><br>
> Can you try to check if the pointer of the returned string is the<br>
> right one (IE, buff) but happen to contain garbage or the pointer<br>
> itself is garbage ?<br>
<br>
</div>I did some digging, and found that the pointer is correct but the target<br>
is garbage.<br> <br></blockquote><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Also, I may have found the cause: if buf is changed from a static array<br>
to a dynamic one (with .length set to 256 in the ctor) then the<br>
corruption goes away. I'm wondering if maybe the size of the struct is<br>
causing it to overflow the stack?</blockquote><div><br></div>This is a self-specific pointer (==slice) problem.<div><br></div><div><div>        auto makeTransientString() {</div><div>            auto tsa = TransientStringArray([ "ab", "cd", "ef" ]);</div>
<div>            //return joiner(tsa);</div><div>            auto x = joiner(tsa); return x; // jsut same as above by RVO</div><div>            // In here, x._current points tsa.buf,</div><div>            // but tsa.buf is allocated in the stack and</div>
<div>            // will be corrupted after returning makeTransientString()</div><div>        } </div></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

It would explain why the corruption starts to happen at the 4th level of<br>
nested function calls, since on Linux the default stack size is approx.<br>
4 KB, and the size of dchar[256] plus 1 or 2 other struct members makes<br>
the size of the struct a little over 1 KB, so 4 copies of them on the<br>
stack would cause an overflow.</blockquote><div> </div><div>Calling <span style="font-family:arial,sans-serif;font-size:14px">func2(result); is accidentally works IMO.</span></div><div><span style="font-family:arial,sans-serif;font-size:14px"><br>
</span></div><div><font face="arial, sans-serif"><span style="font-size:14px">The root cause is saving _items.front in joiner.Result.ctor, and using it later.</span></font></div><div><span style="font-family:arial,sans-serif;font-size:14px">If you calculate joiner.Result.front every time, problem will disappear.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:14px"><br></span></div><div><font face="arial, sans-serif"><span style="font-size:14px"><div><div>        @property auto ref front()</div><div>        {</div><div>            //return _current.front;</div>
<div>            return _items.front.front;</div><div>        }</div></div><div><br></div></span></font></div><div><span style="font-family:arial,sans-serif;font-size:14px">Kenji Hara</span></div></div></div>