[Vm-dev] Win64 Builds broken, slow build times?

Wed Aug 12 15:42:02 UTC 2020

>From https://archive.is/J01oT, 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...
Does it help?

Le mer. 12 août 2020 à 17:06, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> Hi Eliot,
> also, did you see my comment
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498#issuecomment-647189330
> removing -mno-stack-arg-probe option from the makefile solves the cygwin
> build.
> See also
> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/920248dc54ecbcadd9121058360081665d3c7460#r40066039
> Maybe we can just make the option msvc-build specific as a temporary
> workaround...
>
> Le mer. 12 août 2020 à 16:47, Eliot Miranda <eliot.miranda at gmail.com> a
> écrit :
>
>>
>> Hi Tom, Hi Marcel,
>>
>>     I also see that the mingw32/Cygwin/clang build is broken but the
>> MSVC/Clang build is not.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> HTH
>>
>> On May 18, 2020, at 11:40 PM, Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>> 
>> Hi Eliot, hi Tom,
>>
>> I reported this issue about a week ago:
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498
>>
>> Bintray version squeak.cog.spur_win64x64_202005170205 is still broken.
>> Segfaults on startup.
>>
>> Best,
>> Marcel
>>
>> Am 19.05.2020 01:02:06 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> Hi Tom,
>>
>>
>> > On May 18, 2020, at 1:44 PM, Tom Beckmann wrote:
>> >
>> > 
>> > Hi everyone,
>> >
>> > 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:
>> >
>> > Thread 1 received signal SIGSEGV, Segmentation fault.
>> > 0x00000000004016f3 in interpret () at
>> ../../spur64src/vm/gcc3x-cointerp.c:2809
>> > 2809 memset(theStackMemory, 0, stackPagesBytes);
>> > (gdb) bt
>> > #0 0x00000000004016f3 in interpret () at
>> ../../spur64src/vm/gcc3x-cointerp.c:2809
>> > #1 0x000000000052c34c in sqMain (argc=2, argv=0x1dd53a0) at
>> ../../platforms/win32/vm/sqWin32Main.c:1709
>> > #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
>> > #3 0x00000000004013c7 in __tmainCRTStartup () at
>> /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:339
>> > #4 0x00000000004014cb in WinMainCRTStartup () at
>> /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:195
>> >
>> > 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?
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>>
>> > Thank you for any pointers!
>> > Tom
>>
>> Eliot
>> _,,,^..^,,,_ (phone)
>>
>>
>>
>> Eliot
>> _,,,^..^,,,_ (phone)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200812/56ed48cb/attachment.html>