<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Guille,</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 15, 2019 at 8:45 AM Guillermo Polito <<a href="mailto:guillermopolito@gmail.com">guillermopolito@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr">Hi all,<div dir="ltr" class="gmail-m_-979907575056022412gmail_signature"><div dir="ltr"><div></div></div></div><div><br></div><div>With Pablo we have been tracking a bug on win32 that produces a segmentation fault on callback return. We can reproduce it 100% certainly when running the Alien qsort example both in latest pharo and squeak versions.</div><div><br></div><div>After some debugging, it would seem that the thunkEntry function is over-optimized in 32 bits, corrupting the (C) stack. This was particularly boring because compiling the VM in debug mode was taking the bug away :-). We have cornered the bug and checked that callbacks do work ok if we disable optimizations just for the thunkEntry function like this:</div><br>long<br>__attribute__((optimize("O0"))) thunkEntry(void *thunkp, sqIntptr_t *stackp) </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>The thing is that latest mingw which we use for compiling the windows VM even in travis, now comes with gcc 7.4.0 which has a lot more of optimizations than before. Just having O1 also produces the same error.</div><div><br></div><div>We have tried disabling some particular optimizations like fno-combine-stack-adjustments but with no result so far.</div><div><br></div><div>The strange thing is that other callbacks like the ones coming from libgit work ok.</div><div><br></div><div>Has somebody taken a look into this too?</div><div>How would you suggest that we move on with this?</div></div></div></blockquote><div><br></div><div>Before adding the pragma to the source also look at whether using the volatile keyword on variables in thunkProcess fixes the issue; for example </div><div><br></div><div>    volatile VMCallbackContext vmcc;</div><div>    volatile VMCallbackContext *previousCallbackContext;</div><div>    volatile int flags, returnType;</div><div><br></div><div>.  The other thing to do is to generate the machine code for thinkProcess with gcc 7.x and an older version that does not crash and compare to try and find out what specific optimization is causing the crash.</div><div><br></div><div>Finally, if you do find you have to use the pragma, please write the fix as</div><div><br></div><div><span style="color:rgb(0,0,0)">long </span><span style="color:rgb(0,0,0)">__attribute__((optimize("O0"))</span><span style="color:rgb(0,0,0)">)</span></div><div><span style="color:rgb(0,0,0)">thunkEntry(void *thunkp, sqIntptr_t *stackp)</span><br></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">to keep the definition starting on a new line, which helps when using command-line tools to look for definitions outside of an </span><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">ide.</span></font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>From our side, we think that using a pragma to disable optimizations for thunkEntry in the case of win32 looks okeyish at least to make the bug go away.</div></div></div></blockquote><div><br></div><div>Yes, but I expect it is actually that the volatile keyword has not been used (a mistake of mine).  Here's a relevant stack overflow answer:</div><div><a href="https://stackoverflow.com/questions/7996825/why-volatile-works-for-setjmp-longjmp">https://stackoverflow.com/questions/7996825/why-volatile-works-for-setjmp-longjmp </a></div><div><br></div><div>And if volatile does fix the issue, please apply it to the other thinkEntry implementations.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Cheers,<br></div><div>Guille & Pablo</div></div></div>
</blockquote></div><br clear="all"><div>Cheers!</div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div></div>