[cffi-devel] :pointer size on 64-bit OS's
I am receiving reports of nasty intermittent crashes when lispbuilder-sdl is run within a 32-bit Lisp (SBCL & CCL) on a 64-bit OS (Windows 7 and OSX). A 32- bit Lisp is used because the SDL library is 32-bit. No problems are reported using Lispworks/32-bit in Windows 7. The errors reports state that the Lisp debugger is invoked on the CFFI call to "SDL_PollEvent" (stack trace below). This is intermittent in that it might happen almost immediately, or after several thousand times through the event loop. SDL_PollEvent takes an SDL_Event struct as a parameter. SDL_Event looks like this; (cffi:defcunion SDL-Event (type :unsigned-char) (active SDL-Active-Event) (key SDL-Keyboard-Event) (motion SDL-Mouse-Motion-Event) (button SDL-Mouse-Button-Event) (jaxis SDL-Joy-Axis-Event) (jball SDL-Joy-Ball-Event) (jhat SDL-Joy-Hat-Event) (jbutton SDL-Joy-Button-Event) (resize SDL-Resize-Event) (expose SDL-Expose-Event) (quit SDL-Quit-Event) (user SDL-User-Event) (syswm SDL-Sys-WM-Event)) A few of the SDL_Events structs include pointers... (cffi:defcstruct SDL-User-Event (type :unsigned-char) (code :int) (data1 :pointer) (data2 :pointer)) (cffi:defcstruct SDL-Sys-WM-Event (type :unsigned-char) (msg :pointer)) If :pointer is created as a 64-bit pointer instead of 32-bit then I can foresee a problem as SDL_Event created by CFFI is larger than expected by SDL_PollEvent. So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size of :pointer on a 64-bit OS? Stack trace for SBCL/32-bit below; debugger invoked on a SIMPLE-ERROR: EXCEPTION_ACCESS_VIOLATION Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Ignore runtime option --load "load.lisp". 1: [ABORT ] Skip rest of --eval and --load options. 2: Skip to toplevel READ/EVAL/PRINT loop. 3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ("bogus stack frame") 0] ba 0: ("bogus stack frame") 1: ("foreign function: #x757A8112") 2: ("foreign function: #x68132D60") 3: ("foreign function: #x68106812") 4: ("foreign function: #x6810684B") 5: (LISPBUILDER-SDL-CFFI::SDL-POLL-EVENT #.(SB-SYS:INT-SAP #X02106EC0)) - Luke
On Thu, May 27, 2010 at 1:06 AM, Luke Crook <luke@balooga.com> wrote:
So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size of :pointer on a 64-bit OS?
32-bit. You can check it yourself with (cffi:foreign-type-size :pointer). -- Luís Oliveira http://r42.eu/~luis/
On Thu, 27 May 2010, Luís Oliveira wrote:
On Thu, May 27, 2010 at 1:06 AM, Luke Crook <luke@balooga.com> wrote:
So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size of :pointer on a 64-bit OS?
32-bit. You can check it yourself with (cffi:foreign-type-size :pointer).
On my Slackware 13, 64-bit box, #include <iostream> int main(int, char**) { std::cout << sizeof(void *) <<"\n"; return 0; } prints "8". - Daniel
On Thu, May 27, 2010 at 2:31 AM, Daniel Herring <dherring@tentpost.com> wrote:
So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size of :pointer on a 64-bit OS? [...] std::cout << sizeof(void *) <<"\n"; [...] prints "8".
But that is coming from neither SBCL/CCL nor a 32-bit compiler. :-) -- Luís Oliveira http://r42.eu/~luis/
On Wed, May 26, 2010 at 11:44 PM, Luís Oliveira <luismbo@gmail.com> wrote:
On Thu, May 27, 2010 at 2:31 AM, Daniel Herring <dherring@tentpost.com> wrote:
So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size of :pointer on a 64-bit OS? [...] std::cout << sizeof(void *) <<"\n"; [...] prints "8".
But that is coming from neither SBCL/CCL nor a 32-bit compiler. :-)
Yes, the size is 4 (see output below). Again, this problem is only observable on 32-bit SBCL running on top of 64-bit Windows. This problem has never occurred on Linux or OS X or any other OS. The problem cannot be reproduced on 32-bit versions of Windows. The problem doesn't appear in Lispworks or CLISP. (CCL 32-bit doesn't run on 64-bit Windows.) I think I've managed to reproduce it in Allegro CL, but only with optimize speed turned on, and I didn't get backtrace so I can't really be sure. So unless you have a system that meets those parameters, you probably won't be able to reproduce this bug. * (foreign-type-size :pointer) 4 * *features* (CFFI-FEATURES:FLAT-NAMESPACE CFFI-FEATURES:X86 CFFI-FEATURES:WINDOWS :CFFI CFFI-SYS::FLAT-NAMESPACE :WINDOWS :LITTLE-ENDIAN :ASDF :ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :WIN32 :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS :CYCLE-COUNTER :INLINE-CONSTANTS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC) -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay
Perhaps you are jumping the gun with theories as to why it doesn't work. Perhaps 32-bit SBCL simply isn't reliable when run on 64-bit Windows. One thing to try would be a small test that calls any foreign function in a tight loop. Let that run for a bit, see if it explodes. If it works, add some consing to the loop to make the the GC is behaving. After that I'm not sure what the next step is in morphing it toward the code known to fail. Maybe go in the opposite direction, stripping down the failing code to a minimum (turn off sound, input, and any other non-video SDL subsystems, rip out all the rendering and event handling, etc.) (I personally am amazed whenever anything works on any version of Windows, but anticipation of these sort of problems is exactly when I never seriously considered SBCL or CCL for deploying applications to other people)
participants (5)
-
Andy Hefner -
Daniel Herring -
Elliott Slaughter -
Luke Crook -
Luís Oliveira