<div dir="ltr"><div>Sorry to fragment the thread like this, but maybe this helps too:</div><div><a href="https://stackoverflow.com/questions/52406183/mingw-stack-size-reserved-or-committed">https://stackoverflow.com/questions/52406183/mingw-stack-size-reserved-or-committed</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 12 août 2020 à 18:32, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>So the question is why is 
<code>-mno-stack-arg-probe</code> required, optimization apart?</div><div>If for no other purpose than optimization, we shall better remove this form cygwin build, until we find out how to reserve (committed) stack space...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 12 août 2020 à 17:42, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>From <a href="https://archive.is/J01oT" target="_blank">https://archive.is/J01oT</a>, my understanding is that if we remove stack-probe, then we are not anymore protected from a stack overflow when trying to allocate more than a page size on stack...</div><div>Does it help?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 12 août 2020 à 17:06, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Eliot,</div><div>also, did you see my comment <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498#issuecomment-647189330" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498#issuecomment-647189330</a></div><div>removing<code> -mno-stack-arg-probe </code>option from the makefile solves the cygwin build.</div><div>See also <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/920248dc54ecbcadd9121058360081665d3c7460#r40066039" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/920248dc54ecbcadd9121058360081665d3c7460#r40066039</a></div><div>Maybe we can just make the option msvc-build specific as a temporary workaround...<br>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 12 août 2020 à 16:47, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="auto"><div dir="ltr">Hi Tom, Hi Marcel,</div><div dir="ltr"><br></div><div dir="ltr">    I also see that the mingw32/Cygwin/clang build is broken but the MSVC/Clang build is not.  </div><div dir="ltr"><br></div><div dir="ltr">If you use gdb to find out where the mingw32/Cygwin/clang breaks you will see that it is in the zeroing of the stack zone memory after the initial alloca of the stack zone.  The stack pointer gets set to a lower value by the alloca, as expected, but the stack memory is not committed so when the memset starts writing to the memory pointed to by the stack pointer it segfaults.</div><div dir="ltr"><br></div><div dir="ltr">I initially had the same problem with the MSVC/Clang build, but at a different point, the JIT.  The JIT stack allocates the memory it uses for generating abstract instructions, etc, when generating machine code.  It can stack allocate over a megabyte.  To fix the crash I used the linker’s /STACK=size,committed flag to give the executable a 2mb fully committed stack, and this fixed the crashes.</div><div dir="ltr"><br></div><div dir="ltr">I am using the MSVC/Clang build for Terf and we have had no problems with the core VM since.  However, in looking at SoundPlugin issues I did try the mingw32/Cygwin/clang build last week and saw the stack zone alloca crash that I expect is the cause of the breakage you observe.  I did have time to add a —stack size,committed flag to attempt to give the executable a 2mb fully committed stack, but this did not work and did not fix the crash, which remains in the same place.  I conclude that the way I tried to add the —stack size,committed flag is incorrect, although the linked did not produce any error messages.</div><div dir="ltr"><br></div><div dir="ltr">I wish I had time to look at this but I don’t.  If anyone does have time, then my suggestion is to do a MSVC/Clang build alongside the mingw32/Cygwin/clang one, and find out how to introspect the executable to list its stack allocation parameters.  I know that MSVC’s editbin can be used to set these parameters but don’t know of a program to list them.  One obvious test is to use editbin to set the stack allocation parameters of the mingw32/Cygwin/clang build.  If my hypothesis is correct then it should produce a vm that starts up, and then the attempt to fix is simple, find out how to get the mingw32/Cygwin/clang linker to set correctly the stack allocation parameters.</div><div dir="ltr"><br></div><div dir="ltr">HTH</div><div dir="ltr"><br><blockquote type="cite">On May 18, 2020, at 11:40 PM, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br></blockquote></div><blockquote type="cite"><div dir="ltr"><span><div id="gmail-m_-7892406174410771040gmail-m_-1817402134357957024gmail-m_-4316124909115678733gmail-m_-6857771796185086164__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
                                        Hi Eliot, hi Tom,<div><br></div><div>I reported this issue about a week ago:</div><div><span style="font-size:10pt"><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498</a></span><br></div><div><br></div><div>Bintray version squeak.cog.spur_win64x64_202005170205 is still broken. Segfaults on startup.</div><div><br></div><div>Best,</div><div>Marcel</div><div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px">
                        <p style="color:rgb(170,170,170);margin-top:10px">Am 19.05.2020 01:02:06 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> <br>Hi Tom,<br><br><br>> On May 18, 2020, at 1:44 PM, Tom Beckmann <u></u> wrote:<br>> <br>> <br>> Hi everyone,<br>> <br>> I just tried building build.win64x64/squeak.cog.spur on the Cog branch but got a segfault on startup. I then tentatively went back 10 commits (HEAD~10) and it worked again. This is the output I received in gdb:<br>> <br>> Thread 1 received signal SIGSEGV, Segmentation fault.<br>> 0x00000000004016f3 in interpret () at ../../spur64src/vm/gcc3x-cointerp.c:2809<br>> 2809                    memset(theStackMemory, 0, stackPagesBytes);<br>> (gdb) bt<br>> #0  0x00000000004016f3 in interpret () at ../../spur64src/vm/gcc3x-cointerp.c:2809<br>> #1  0x000000000052c34c in sqMain (argc=2, argv=0x1dd53a0) at ../../platforms/win32/vm/sqWin32Main.c:1709<br>> #2  0x000000000052c7f2 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0xfc437c "../../../Squeak6.0alpha-19582-64bit-202003021730-Windows/Squeak6.0alpha-19582-64bit.image", nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1802<br>> #3  0x00000000004013c7 in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:339<br>> #4  0x00000000004014cb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:195<br>> <br>> The main reason I'm writing, however, is that I only haven't done a bisect yet because building the VM appears unusually slow, when compared to building on Linux, as in, orders of magnitude slower. I believe I have the same setup as we do on appveyor on windows using cygwin64. Incremental builds seem to recompile a lot of files and it appears there are race conditions when building with multiple threads (-j8). Are these known limitations of the Windows build or am I potentially just having the wrong setup?<br><br>I hope it is simply wrong setup.  I have been making these commits in recent weeks in the context of getting 64-bit Terf working.  Terf is 3D ICC’s Croquet-derived business communications tool which was formerly known as Teleplace and Qwaq forums and was the context in which OpenSmalltalk-vm was conceived.<br><br>I am building 64-bits using Clang 10 and MSVC and I assure you this works.  See HowToBuild for how to build using this configuration.<br><br>Your configuration may be obsolete or it may be valid, and if valid we should fix it.  Can you list exactly what versions of software (Cygwin or mingw, gcc, clang) you’re using your build?<br><br><br>> Thank you for any pointers!<br>> Tom<br><br>Eliot<br>_,,,^..^,,,_ (phone)<u></u></div></blockquote>
                                        </div></span></div></blockquote><br><div><br>Eliot<br><div dir="ltr"><span style="background-color:rgba(255,255,255,0)">_,,,^..^,,,_ (phone)</span></div></div></div></blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>