From: SourceForge.net <no...@so...> - 2006-04-04 05:51:47
|
Bugs item #1463994, was opened at 2006-04-03 23:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-04-24 17:42:26
|
Bugs item #1463994, was opened at 2006-04-04 07:51 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 19:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-04-24 18:28:10
|
Bugs item #1463994, was opened at 2006-04-03 23:51 Message generated for change (Comment added) made by junrue You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jack D. Unrue (junrue) Date: 2006-04-24 12:28 Message: Logged In: YES user_id=119851 The testcase exercises one of the two primary variations of the SetTimer Win32 API. But either way, the timer notification is processed in the context of the thread that owns the message queue. The MSDN documentation states: "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER" The above requirement to "dispatch messages in the calling thread" is accomplished in my testcase via the run-message-loop function. Also, to empirically verify that there is not an additional thread involved, I used a utility available for Windows called Process Explorer to inspect the lisp.exe process, specifically to watch for threads being created and running, prior to executing my testcase and while it was running. I verified that no additional threads are created for the timer. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 11:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-04-28 11:29:38
|
Bugs item #1463994, was opened at 2006-04-04 07:51 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-04-28 13:29 Message: Logged In: YES user_id=377168 It appears that the bug does not depend on GF/CLOS. You can replace the callback with a call to BREAK. Calling EXT:GC therein yields, on my machine (MS-VC build): [4]> (run-timer) *** - illegal foreign data type #(NIL #<SYSTEM-FUNCTION CLOS::%ALLOCATE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%INITIALIZE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%SHARED-INITIALIZE>) or Break 1 [13]> (ext:gc) *** - illegal foreign data type (524288) > :bt1 [likely crashes] which indicates that CLISP's heap is corrupt. This can be caused either by a bad interface (e.g. incorrect declarations) or some bug in def-call-in or a similar location ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-24 20:28 Message: Logged In: YES user_id=119851 The testcase exercises one of the two primary variations of the SetTimer Win32 API. But either way, the timer notification is processed in the context of the thread that owns the message queue. The MSDN documentation states: "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER" The above requirement to "dispatch messages in the calling thread" is accomplished in my testcase via the run-message-loop function. Also, to empirically verify that there is not an additional thread involved, I used a utility available for Windows called Process Explorer to inspect the lisp.exe process, specifically to watch for threads being created and running, prior to executing my testcase and while it was running. I verified that no additional threads are created for the timer. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 19:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-04-28 17:51:10
|
Bugs item #1463994, was opened at 2006-04-03 23:51 Message generated for change (Comment added) made by junrue You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 11:51 Message: Logged In: YES user_id=119851 While the behavior on my machine is slightly different (I get the Windows GPF dialog instead of a diagnostic message from CLISP), I too see that BREAK triggers the crash. So I agree it has nothing to do with CLOS. I have double-checked my declarations against the C declarations in the Windows header files, and I'm as sure as I can be that they're correct. I've also checked that FFI:SIZEOF reports the expected sizes for each of the parameter types of the callback. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-28 05:29 Message: Logged In: YES user_id=377168 It appears that the bug does not depend on GF/CLOS. You can replace the callback with a call to BREAK. Calling EXT:GC therein yields, on my machine (MS-VC build): [4]> (run-timer) *** - illegal foreign data type #(NIL #<SYSTEM-FUNCTION CLOS::%ALLOCATE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%INITIALIZE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%SHARED-INITIALIZE>) or Break 1 [13]> (ext:gc) *** - illegal foreign data type (524288) > :bt1 [likely crashes] which indicates that CLISP's heap is corrupt. This can be caused either by a bad interface (e.g. incorrect declarations) or some bug in def-call-in or a similar location ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-24 12:28 Message: Logged In: YES user_id=119851 The testcase exercises one of the two primary variations of the SetTimer Win32 API. But either way, the timer notification is processed in the context of the thread that owns the message queue. The MSDN documentation states: "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER" The above requirement to "dispatch messages in the calling thread" is accomplished in my testcase via the run-message-loop function. Also, to empirically verify that there is not an additional thread involved, I used a utility available for Windows called Process Explorer to inspect the lisp.exe process, specifically to watch for threads being created and running, prior to executing my testcase and while it was running. I verified that no additional threads are created for the timer. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 11:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-04-28 18:13:49
|
Bugs item #1463994, was opened at 2006-04-03 23:51 Message generated for change (Comment added) made by junrue You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 12:13 Message: Logged In: YES user_id=119851 I should also mention that this testcase is a manual translation (and abbreviated version) of equivalent code that I've written via CFFI as part of a library. This equivalent code that uses a timer callback works without problems on LispWorks 4.4.6. I've attached a slightly simplified version of the testcase that gets rid of the defclass/defmethod noise and where the timer-proc callback function simply calls BREAK. ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 11:51 Message: Logged In: YES user_id=119851 While the behavior on my machine is slightly different (I get the Windows GPF dialog instead of a diagnostic message from CLISP), I too see that BREAK triggers the crash. So I agree it has nothing to do with CLOS. I have double-checked my declarations against the C declarations in the Windows header files, and I'm as sure as I can be that they're correct. I've also checked that FFI:SIZEOF reports the expected sizes for each of the parameter types of the callback. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-28 05:29 Message: Logged In: YES user_id=377168 It appears that the bug does not depend on GF/CLOS. You can replace the callback with a call to BREAK. Calling EXT:GC therein yields, on my machine (MS-VC build): [4]> (run-timer) *** - illegal foreign data type #(NIL #<SYSTEM-FUNCTION CLOS::%ALLOCATE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%INITIALIZE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%SHARED-INITIALIZE>) or Break 1 [13]> (ext:gc) *** - illegal foreign data type (524288) > :bt1 [likely crashes] which indicates that CLISP's heap is corrupt. This can be caused either by a bad interface (e.g. incorrect declarations) or some bug in def-call-in or a similar location ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-24 12:28 Message: Logged In: YES user_id=119851 The testcase exercises one of the two primary variations of the SetTimer Win32 API. But either way, the timer notification is processed in the context of the thread that owns the message queue. The MSDN documentation states: "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER" The above requirement to "dispatch messages in the calling thread" is accomplished in my testcase via the run-message-loop function. Also, to empirically verify that there is not an additional thread involved, I used a utility available for Windows called Process Explorer to inspect the lisp.exe process, specifically to watch for threads being created and running, prior to executing my testcase and while it was running. I verified that no additional threads are created for the timer. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 11:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-05-03 17:52:45
|
Bugs item #1463994, was opened at 2006-04-04 07:51 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-05-03 19:52 Message: Logged In: YES user_id=377168 Uhoh, it's a hairy stack/register possibly GC consistency bug somewhere in CLISP. I've enabled -DDEBUG_BACKTRACE and -DSAFETY=1 and the FFI testsuite does not pass anymore (1 error in all tests): Form: (LIST (FUNCALL FPCALLBACK 3.5d0) *X*) CORRECT: (3.5 3.5d0) CLISP : ERROR NIL cannot be converted to the foreign type SINGLE-FLOAT I think it's related (callback involved). [3]> (run-timer) eval.d:5779:w/s/b/t: before: circularity! [0/0x32a264]> #<COMPILED-FUNCTION SYS::COERCE-TO-CONDITION> delta: STACK=0; SP=4 6 [1/0x32a31c]> #<SYSTEM-FUNCTION CL::SIGNAL> 1 args delta: STACK=18; SP=107374064 4 [2/0x3290ac]> #<COMPILED-FUNCTION MOP::COMPUTE-EFFECTIVE-METHOD-AS-FUNCTION-FORM > delta: STACK=4; SP=251 [3/0x329498]> #<COMPILED-FUNCTION MOP::COMPUTE-EFFECTIVE-METHOD-AS-FUNCTION> *** - handle_fault error2 ! address = 0x1 not in [0x1a3d0000,0x1a500ee8) ! SIGSEGV cannot be cured. Fault address = 0x1. Permanently allocated: 88000 bytes. Currently in use: 1827664 bytes. Free space: 326824 bytes ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 20:13 Message: Logged In: YES user_id=119851 I should also mention that this testcase is a manual translation (and abbreviated version) of equivalent code that I've written via CFFI as part of a library. This equivalent code that uses a timer callback works without problems on LispWorks 4.4.6. I've attached a slightly simplified version of the testcase that gets rid of the defclass/defmethod noise and where the timer-proc callback function simply calls BREAK. ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 19:51 Message: Logged In: YES user_id=119851 While the behavior on my machine is slightly different (I get the Windows GPF dialog instead of a diagnostic message from CLISP), I too see that BREAK triggers the crash. So I agree it has nothing to do with CLOS. I have double-checked my declarations against the C declarations in the Windows header files, and I'm as sure as I can be that they're correct. I've also checked that FFI:SIZEOF reports the expected sizes for each of the parameter types of the callback. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-28 13:29 Message: Logged In: YES user_id=377168 It appears that the bug does not depend on GF/CLOS. You can replace the callback with a call to BREAK. Calling EXT:GC therein yields, on my machine (MS-VC build): [4]> (run-timer) *** - illegal foreign data type #(NIL #<SYSTEM-FUNCTION CLOS::%ALLOCATE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%INITIALIZE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%SHARED-INITIALIZE>) or Break 1 [13]> (ext:gc) *** - illegal foreign data type (524288) > :bt1 [likely crashes] which indicates that CLISP's heap is corrupt. This can be caused either by a bad interface (e.g. incorrect declarations) or some bug in def-call-in or a similar location ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-24 20:28 Message: Logged In: YES user_id=119851 The testcase exercises one of the two primary variations of the SetTimer Win32 API. But either way, the timer notification is processed in the context of the thread that owns the message queue. The MSDN documentation states: "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER" The above requirement to "dispatch messages in the calling thread" is accomplished in my testcase via the run-message-loop function. Also, to empirically verify that there is not an additional thread involved, I used a utility available for Windows called Process Explorer to inspect the lisp.exe process, specifically to watch for threads being created and running, prior to executing my testcase and while it was running. I verified that no additional threads are created for the timer. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 19:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-05-24 16:09:04
|
Bugs item #1463994, was opened at 2006-04-04 07:51 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ffi Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: Jack D. Unrue (junrue) Assigned to: Jörg Höhle (hoehle) Summary: Win32 def-call-in GPFs when calling a generic function Initial Comment: I have attached a testcase that demonstrates a GPF on Win32 when a def-call-in that is declared with (:language :stdc-stdcall) invokes a generic function. A nearly identical def-call-in that invokes a normal function does not crash. Please see the comments at the top of the testcase for more details. My clisp build is: GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-05-24 18:09 Message: Logged In: YES user_id=377168 I've written some lines of code which I thought were mostly identical to the original code. However, my code does not trigger the bug. It's similar in that it uses call-out + call-in, with :language :stdc-stdcall. It's different in that it does not use any external function. Thus there's potential for a possibly bogus ffcall behaving as a convolution with my code, since it calls itself (the vacall trampoline), which is different from the original code, where MS-Windows API is called. (use-package "FFI") (def-c-type tfun-sc (c-function (:arguments (hwnd ffi:c-pointer) (msg ffi:uint) (id ffi:uint) (time ffi:ulong)) (:language :stdc-stdcall) ;(:language :stdc) (:return-type uint))) (defun cb-gc (hwnd msg id time) (declare (ignore hwnd msg id time)) (ext:gc) 12356) (defun cb-break (hwnd msg id time) (declare (ignore hwnd msg id time)) (break "in signal loop")) (setq callbackgc (with-c-var (x 'tfun-sc #'cb-gc) x)) (funcall callbackgc nil 1 2 3) (setq callbackbreak (with-c-var (x 'tfun-sc #'cb-break) x)) (funcall callbackbreak nil 111111 2222222 333333333) I'm wondering why I can't find the 1111 222 3333 args close to each other in the backtrace :bt1 #<FUNCTION CB-BREAK (HWND MSG ID TIME) (DECLARE (SYSTEM::IN-DEFUN CB-BREAK) (IGNORE HWND MSG ID TIME)) (BLOCK CB-BREAK (BREAK "in signal loop"))> 4 - #(C-POINTER 0 UINT 0 UINT 0 ULONG 0) - #<FUNCTION CB-BREAK (HWND MSG ID TIME) (DECLARE (SYSTEM::IN-DEFUN CB-BREAK) (IGNORE HWND MSG ID TIME)) (BLOCK CB-BREAK (BREAK "in signal loop"))> - UINT - UINT - 333333333 ; huh? weshalb Args so komisch zerhackt? <14> #<SYSTEM-FUNCTION FFI::FOREIGN-CALL-OUT> 5 - 2222222 ; weitere Args? <15> #<SYSTEM-FUNCTION FUNCALL> 5 - 111111 ; weitere Args - NIL - #<FOREIGN-FUNCTION #x00BD1B60> ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-03 19:52 Message: Logged In: YES user_id=377168 Uhoh, it's a hairy stack/register possibly GC consistency bug somewhere in CLISP. I've enabled -DDEBUG_BACKTRACE and -DSAFETY=1 and the FFI testsuite does not pass anymore (1 error in all tests): Form: (LIST (FUNCALL FPCALLBACK 3.5d0) *X*) CORRECT: (3.5 3.5d0) CLISP : ERROR NIL cannot be converted to the foreign type SINGLE-FLOAT I think it's related (callback involved). [3]> (run-timer) eval.d:5779:w/s/b/t: before: circularity! [0/0x32a264]> #<COMPILED-FUNCTION SYS::COERCE-TO-CONDITION> delta: STACK=0; SP=4 6 [1/0x32a31c]> #<SYSTEM-FUNCTION CL::SIGNAL> 1 args delta: STACK=18; SP=107374064 4 [2/0x3290ac]> #<COMPILED-FUNCTION MOP::COMPUTE-EFFECTIVE-METHOD-AS-FUNCTION-FORM > delta: STACK=4; SP=251 [3/0x329498]> #<COMPILED-FUNCTION MOP::COMPUTE-EFFECTIVE-METHOD-AS-FUNCTION> *** - handle_fault error2 ! address = 0x1 not in [0x1a3d0000,0x1a500ee8) ! SIGSEGV cannot be cured. Fault address = 0x1. Permanently allocated: 88000 bytes. Currently in use: 1827664 bytes. Free space: 326824 bytes ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 20:13 Message: Logged In: YES user_id=119851 I should also mention that this testcase is a manual translation (and abbreviated version) of equivalent code that I've written via CFFI as part of a library. This equivalent code that uses a timer callback works without problems on LispWorks 4.4.6. I've attached a slightly simplified version of the testcase that gets rid of the defclass/defmethod noise and where the timer-proc callback function simply calls BREAK. ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-28 19:51 Message: Logged In: YES user_id=119851 While the behavior on my machine is slightly different (I get the Windows GPF dialog instead of a diagnostic message from CLISP), I too see that BREAK triggers the crash. So I agree it has nothing to do with CLOS. I have double-checked my declarations against the C declarations in the Windows header files, and I'm as sure as I can be that they're correct. I've also checked that FFI:SIZEOF reports the expected sizes for each of the parameter types of the callback. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-28 13:29 Message: Logged In: YES user_id=377168 It appears that the bug does not depend on GF/CLOS. You can replace the callback with a call to BREAK. Calling EXT:GC therein yields, on my machine (MS-VC build): [4]> (run-timer) *** - illegal foreign data type #(NIL #<SYSTEM-FUNCTION CLOS::%ALLOCATE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%INITIALIZE-INSTANCE> #<SYSTEM-FUNCTION CLOS::%SHARED-INITIALIZE>) or Break 1 [13]> (ext:gc) *** - illegal foreign data type (524288) > :bt1 [likely crashes] which indicates that CLISP's heap is corrupt. This can be caused either by a bad interface (e.g. incorrect declarations) or some bug in def-call-in or a similar location ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-04-24 20:28 Message: Logged In: YES user_id=119851 The testcase exercises one of the two primary variations of the SetTimer Win32 API. But either way, the timer notification is processed in the context of the thread that owns the message queue. The MSDN documentation states: "When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER" The above requirement to "dispatch messages in the calling thread" is accomplished in my testcase via the run-message-loop function. Also, to empirically verify that there is not an additional thread involved, I used a utility available for Windows called Process Explorer to inspect the lisp.exe process, specifically to watch for threads being created and running, prior to executing my testcase and while it was running. I verified that no additional threads are created for the timer. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-04-24 19:42 Message: Logged In: YES user_id=377168 Can you please check whether using the timer may cause re-entry within a different thread? CLISP does not support threads and trying to get them via signals is going to crash more or less fast, as the environment is not setup properly. So please ensure that this callback timer code does not create a thread in your back where it calls your handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1463994&group_id=1355 |