Hi,
Win32 FFI fails for some time now. For example, load latest versions of FFI from http://source.squeak.org/FFI Then try this snippet:
FFIPluginTests new testGenericDoubleCall.
And you'll get a segmentation fault, crash.dmp. The latest vmI found in bintray already has the problem. https://dl.bintray.com/opensmalltalk/vm/:cog_win32x86_squeak.cog.spur_201606...
This bug delayed the Win64 squeak.stack.spur delivery, because I thought I introduced a regression somewhere...
I did not have time to check other OSes, but it would be worth trying. (Before declaring any VM+plugins as stable...)
If someone has a way to easily dissect without precompiled artifacts, let me know.
Nicolas
2016-08-19 18:29 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Hi,
Win32 FFI fails for some time now. For example, load latest versions of FFI from http://source.squeak.org/FFI Then try this snippet:
FFIPluginTests new testGenericDoubleCall.
And you'll get a segmentation fault, crash.dmp. The latest vmI found in bintray already has the problem.
Hem, the oldest VM, not the latest
https://dl.bintray.com/opensmalltalk/vm/:cog_win32x86_squeak.cog.spur_ 201606301459.zip
This bug delayed the Win64 squeak.stack.spur delivery, because I thought I introduced a regression somewhere...
I did not have time to check other OSes, but it would be worth trying. (Before declaring any VM+plugins as stable...)
If someone has a way to easily dissect without precompiled artifacts, let me know.
err, bissect not dissect
Nicolas
So win32 FFI test crash the VM if compiled with gcc. But tests pass if compiled with clang (i686-w64-mingw32-clang on cygwin64)
---------------- details following -----------------
The problem with gcc is the famous ALLOCA_LIES_SO_USE_GETSP Indeed, alloca reserve 16 more bytes than necessary. That is, it answers a value, but increment stack pointer = return alloca'd + 16 It's wrong because we want to pile up FFI args starting at stack pointer, just above the future return address.
So there is a hack in code generation that used to workaround the problem: use SP instead of alloca'd value for marshalling FFI args. Unfortunately as we could have guessed it was fragile... Recent versions of gcc do use the 16 extra bytes !!! Indeed it seems that the function calls that are used for marshalling FFI arguments will use SP,SP+4,SP+8 and SP+12 for their own arguments, without incrementing SP first Thus when we try and fill the FFI argument stack, we break the own stack of these functions... Since most of these arguments are pointers (oops and calloutState), then we very soon SEGV.
2016-08-19 19:05 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2016-08-19 18:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:
Hi,
Win32 FFI fails for some time now. For example, load latest versions of FFI from http://source.squeak.org/FFI Then try this snippet:
FFIPluginTests new testGenericDoubleCall.
And you'll get a segmentation fault, crash.dmp. The latest vmI found in bintray already has the problem.
Hem, the oldest VM, not the latest
https://dl.bintray.com/opensmalltalk/vm/:cog_win32x86_ squeak.cog.spur_201606301459.zip
This bug delayed the Win64 squeak.stack.spur delivery, because I thought I introduced a regression somewhere...
I did not have time to check other OSes, but it would be worth trying. (Before declaring any VM+plugins as stable...)
If someone has a way to easily dissect without precompiled artifacts, let me know.
err, bissect not dissect
Nicolas
2016-11-08 1:39 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
So win32 FFI test crash the VM if compiled with gcc. But tests pass if compiled with clang (i686-w64-mingw32-clang on cygwin64)
Argh, tests pass only if compiled with clang in debug mode (mvm -d)... mvm -f CC=i686-w64-mingw32-clang will also crash the VM and make some other tests fail. Not having the debug version failing means having to debug optimized code at assembler level. Super Argh!
---------------- details following -----------------
The problem with gcc is the famous ALLOCA_LIES_SO_USE_GETSP Indeed, alloca reserve 16 more bytes than necessary. That is, it answers a value, but increment stack pointer = return alloca'd + 16 It's wrong because we want to pile up FFI args starting at stack pointer, just above the future return address.
So there is a hack in code generation that used to workaround the problem: use SP instead of alloca'd value for marshalling FFI args. Unfortunately as we could have guessed it was fragile... Recent versions of gcc do use the 16 extra bytes !!! Indeed it seems that the function calls that are used for marshalling FFI arguments will use SP,SP+4,SP+8 and SP+12 for their own arguments, without incrementing SP first Thus when we try and fill the FFI argument stack, we break the own stack of these functions... Since most of these arguments are pointers (oops and calloutState), then we very soon SEGV.
2016-08-19 19:05 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:
2016-08-19 18:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:
Hi,
Win32 FFI fails for some time now. For example, load latest versions of FFI from http://source.squeak.org/FFI Then try this snippet:
FFIPluginTests new testGenericDoubleCall.
And you'll get a segmentation fault, crash.dmp. The latest vmI found in bintray already has the problem.
Hem, the oldest VM, not the latest
https://dl.bintray.com/opensmalltalk/vm/:cog_win32x86_squeak .cog.spur_201606301459.zip
This bug delayed the Win64 squeak.stack.spur delivery, because I thought I introduced a regression somewhere...
I did not have time to check other OSes, but it would be worth trying. (Before declaring any VM+plugins as stable...)
If someone has a way to easily dissect without precompiled artifacts, let me know.
err, bissect not dissect
Nicolas
vm-dev@lists.squeakfoundation.org
-
Nicolas Cellier