FFICallback crashes windows spur i386 vm
Hi The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...) Callback instantiation: createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function: int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call: primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case: test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201701130756-83c0e... Image 60343: http://files.pharo.org/image/60/60343.zip P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works Cheers, Alex
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
I don't think that Windows produces crash dumps (or they are empty files), but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application.
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201701130756-83c0e... Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works
Cheers, Alex
Hi Peter, Latest windows VMs produce crash dumps ;) Cheers, Alex On 13 January 2017 at 10:57, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
I don't think that Windows produces crash dumps (or they are empty files), but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application.
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
i386-201701130756-83c0ef1.zip
Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works
Cheers, Alex
On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
Hi Peter,
Latest windows VMs produce crash dumps ;)
Excellent! :) Peter
Cheers, Alex
On 13 January 2017 at 10:57, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
I don't think that Windows produces crash dumps (or they are empty files), but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application.
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
i386-201701130756-83c0ef1.zip
Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works
Cheers, Alex
UPD: Works using 497 windows vm: http://files.pharo.org/vm/pharo-spur32/win/497.zip. Something was changed recently... Cheers, Alex On 13 January 2017 at 11:20, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
Hi Peter,
Latest windows VMs produce crash dumps ;)
Excellent! :)
Peter
Cheers, Alex
On 13 January 2017 at 10:57, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
I don't think that Windows produces crash dumps (or they are empty
files),
but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application.
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8
aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
i386-201701130756-83c0ef1.zip
Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works
Cheers, Alex
UPD: Works with latest *Mac* VM http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201701130756-83c0e... Cheers, Alex On 13 January 2017 at 20:43, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
UPD: Works using 497 windows vm: http://files.pharo.org/vm/ pharo-spur32/win/497.zip. Something was changed recently...
Cheers, Alex
On 13 January 2017 at 11:20, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
Hi Peter,
Latest windows VMs produce crash dumps ;)
Excellent! :)
Peter
Cheers, Alex
On 13 January 2017 at 10:57, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
I don't think that Windows produces crash dumps (or they are empty
files),
but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application.
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8
aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
i386-201701130756-83c0ef1.zip
Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works
Cheers, Alex
UPD: OS-Window and SDL bindings do not work on Mac VM (pharo-mac- i386-201701130756-83c0ef1 <http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201701130756-83c0e...> ) On 13 January 2017 at 22:30, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
UPD: Works with latest *Mac* VM http://files.pharo.org/vm/ pharo-spur32/mac/pharo-mac-i386-201701130756-83c0ef1.zip
Cheers, Alex
On 13 January 2017 at 20:43, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
UPD: Works using 497 windows vm: http://files.pharo.org/vm/ pharo-spur32/win/497.zip. Something was changed recently...
Cheers, Alex
On 13 January 2017 at 11:20, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
Hi Peter,
Latest windows VMs produce crash dumps ;)
Excellent! :)
Peter
Cheers, Alex
On 13 January 2017 at 10:57, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so
on...)
I don't think that Windows produces crash dumps (or they are empty
files),
but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application.
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8
aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
i386-201701130756-83c0ef1.zip
Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works
Cheers, Alex
Hi Aliaksei,
On Jan 13, 2017, at 10:27 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
Callback instantiation:
createCallback ^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) { return function(value); }
FFI call:
primCall: aCallback int8: aNumber ^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case:
test self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201701130756-83c0e... Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues?
vm-dev
P.P.S Iceberg works
Cheers, Alex
I've reproduced the crash in squeak.stack.spur Win32 with latest vm sources (SHA aa11221d9ebb5d60b0b88a2f1f8e27f19909d718) This crashing VM is compiled with gcc via ./mvm -f The Win64 version passes correctly. But it is compiled with clang by default. The Win32 compiled with clang also passes correctly for me. The test is translated in pure Alien for purpose of testing on Squeak 5.0 (see instructions below). -------------------------------------------------------------- from cygwin (or cygwin64) shell: $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ i686-w64-mingw32-clang --version clang version 3.8.1 (tags/RELEASE_381/final) Target: i686-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin $ x86_64-w64-mingw32-clang --version clang version 3.8.1 (tags/RELEASE_381/final) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin -------------------------------------------------------------- $ cd build.win32x86/squeak.stack.spur $ ./mvm -f -- CC=i686-w64-mingw32-clang or for 64 bits: $ cd build.win64x64/squeak.stack.spur $ ./mvm -f -------------------------------------------------------------- $ cat >test.c << END #include "stdint.h" int8_t test(int8_t(*function)(int8_t), int8_t value) { return function(value); } END $ i686-w64-mingw32-clang -c test.c $ i686-w64-mingw32-clang -shared -o build/vm/test.dll test.o $ build/vm/Squeak.exe -------------------------------------------------------------- then from Smalltalk image with Alien properly loaded (Alien-eem.39): Callback>>int8RetInt8: callbackContext regs: regsAlien <signature: #(int8 (*)(int8))> ^callbackContext wordResult: (block value: (regsAlien signedCharAt: 1) asInteger) (for now, above method must be compiled in each Callback subclass since we do not ask Pragma to scan superclass for signatures) TestCase subclass: #AlienCallbackSunit instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Alien-CoreTest' AlienCallbackSunit>>createCallback ^Callback signature: #(int8 (*)(int8)) block: [ :value | value ] AlienCallbackSunit>>primCall: aCallback int8: aNumber | r | (Alien lookup: 'test' inLibrary: 'test.dll') primFFICallResult: (r := Alien new: 1) with: aCallback thunk with: aNumber. ^(r signedCharAt: 1) asInteger AlienCallbackSunit>>test self assert: (self primCall: self createCallback int8: 0) equals: 0 AlienCallbackSunit new test. 2017-01-14 2:53 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Aliaksei,
On Jan 13, 2017, at 10:27 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win- i386-201701130756-83c0ef1.zip Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues?
vm-dev
P.P.S Iceberg works
Cheers, Alex
Hi Nicolas, Hi Esteban, so is it feasible to insist on clang? The mingw compiler is ancient, so my preference is to move to clang. If so, could someone update the HowToBuild to describe the problem with mingw and how to install the clang-based toolchain? On Tue, Jan 17, 2017 at 6:47 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I've reproduced the crash in squeak.stack.spur Win32 with latest vm sources (SHA aa11221d9ebb5d60b0b88a2f1f8e27f19909d718) This crashing VM is compiled with gcc via ./mvm -f
The Win64 version passes correctly. But it is compiled with clang by default. The Win32 compiled with clang also passes correctly for me.
The test is translated in pure Alien for purpose of testing on Squeak 5.0 (see instructions below).
--------------------------------------------------------------
from cygwin (or cygwin64) shell:
$ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ i686-w64-mingw32-clang --version clang version 3.8.1 (tags/RELEASE_381/final) Target: i686-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin
$ x86_64-w64-mingw32-clang --version clang version 3.8.1 (tags/RELEASE_381/final) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin
--------------------------------------------------------------
$ cd build.win32x86/squeak.stack.spur $ ./mvm -f -- CC=i686-w64-mingw32-clang
or for 64 bits:
$ cd build.win64x64/squeak.stack.spur $ ./mvm -f
--------------------------------------------------------------
$ cat >test.c << END #include "stdint.h" int8_t test(int8_t(*function)(int8_t), int8_t value) { return function(value); } END
$ i686-w64-mingw32-clang -c test.c $ i686-w64-mingw32-clang -shared -o build/vm/test.dll test.o $ build/vm/Squeak.exe
--------------------------------------------------------------
then from Smalltalk image with Alien properly loaded (Alien-eem.39):
Callback>>int8RetInt8: callbackContext regs: regsAlien <signature: #(int8 (*)(int8))> ^callbackContext wordResult: (block value: (regsAlien signedCharAt: 1) asInteger)
(for now, above method must be compiled in each Callback subclass since we do not ask Pragma to scan superclass for signatures)
TestCase subclass: #AlienCallbackSunit instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Alien-CoreTest'
AlienCallbackSunit>>createCallback ^Callback signature: #(int8 (*)(int8)) block: [ :value | value ]
AlienCallbackSunit>>primCall: aCallback int8: aNumber | r | (Alien lookup: 'test' inLibrary: 'test.dll') primFFICallResult: (r := Alien new: 1) with: aCallback thunk with: aNumber. ^(r signedCharAt: 1) asInteger
AlienCallbackSunit>>test self assert: (self primCall: self createCallback int8: 0) equals: 0
AlienCallbackSunit new test.
2017-01-14 2:53 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Aliaksei,
On Jan 13, 2017, at 10:27 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi
The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...)
Callback instantiation:
createCallback
^ FFICallback signature: #(int8 (int8)) block: [ :value | value ]
C function:
int8_t test(int8_t(*function)(int8_t), int8_t value) {
return function(value); }
FFI call:
primCall: aCallback int8: aNumber
^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
Test case:
test
self assert: (self primCall: self createCallback int8: 0) equals: 0
Windows 10. VM from today: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386- 201701130756-83c0ef1.zip Image 60343: http://files.pharo.org/image/60/60343.zip
P.S. what is the best place to report FFI / Alien issues?
vm-dev
P.P.S Iceberg works
Cheers, Alex
-- _,,,^..^,,,_ best, Eliot
On 17 Jan 2017, at 19:43, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Nicolas, Hi Esteban,
Hi all,
so is it feasible to insist on clang? The mingw compiler is ancient, so my preference is to move to clang. If so, could someone update the HowToBuild to describe the problem with mingw and how to install the clang-based toolchain?
from cygwin (or cygwin64) shell:
$ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
maybe I am missing something but GCC 5.4 was released in Summer 2016 and is still supported. Couldn't it be that the better optimizers in GCC expose an issue that clang is not capable of exposing (yet?)? just my two cents holger
2017-01-17 19:49 GMT+01:00 Holger Freyther <holger@freyther.de>:
On 17 Jan 2017, at 19:43, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Nicolas, Hi Esteban,
Hi all,
so is it feasible to insist on clang? The mingw compiler is
ancient, so my preference is to move to clang. If so, could someone update the HowToBuild to describe the problem with mingw and how to install the clang-based toolchain?
from cygwin (or cygwin64) shell:
$ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
maybe I am missing something but GCC 5.4 was released in Summer 2016 and is still supported. Couldn't it be that the better optimizers in GCC expose an issue that clang is not capable of exposing (yet?)?
just my two cents
holger
Hi Holger, maybe... One should compile with -O0 to check if it's really about optimization and retry if it solves anything. If yes, then play the game of selecting each individual optimization option. What I know is that the mingw version of gcc have strange stack management with bytes reserved below alloca which is causing some complications in our implemenation of FFI. Personnally I don't have a clue of the reason behind the difference with linux gcc, so without further information, I tend to perceive such differences as a useless and never-ending-source of complications. I'm speaking for myself, but maybe Eliot has the same feeling. Not sure that it's a great choice to abandon gcc support, but it's quite tempting in those circumstances ;)
participants (5)
-
Aliaksei Syrel -
Eliot Miranda -
Holger Freyther -
Nicolas Cellier -
Peter Uhnak