Opened 10 years ago

Closed 10 years ago

#527 closed defect (fixed)

Glut examples in cl-opengl cause "Exception on foreign stack" in Win32

Reported by: codewitch Owned by: gb
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: 1.3
Keywords: cl-opengl cffi Win32 exception crash Cc:


When running (cl-glut-examples:gears), an exception occurs, and the kernel debugger is invoked.

To reproduce:

In your packages directory, you'll need:

  • alexandria
  • babel
  • cffi
  • cl-opengl
  • trivial-features

At the repl:

(asdf:oos 'asdf:load-op :cl-glut-examples)

It is believed to be a CFFI and foreign functions related issue. See IRC log of 3rd June, 2009 for more details.

Attachments (1)

transcript.txt (2.2 KB) - added by codewitch 10 years ago.
Backtrace and registers after qsort loop call.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 10 years ago by gb

  • Status changed from new to assigned

From what I understand, CL-OPENGL expects that FreeGLUT (and possibly other GL-related libraries) are build with 'cdecl' calling conventions. I don't know what's involved in building such a version of FreeGLUT, but presumably someone involved in cl-opengl development does.

Very recent changes in CFFI seem to provide support "stdcall' on CCL/Win32.

It's not clear that there's a CCL bug involved in any of this.

comment:2 Changed 10 years ago by luismbo

FWIW, here's a simpler test case, adapted from the CALLBACKS.QSORT test (part of CFFI's test suite).

(ccl:defcallback qsort-callback (:address a :address b :signed-int)
 (let ((x (ccl:%get-signed-long a))
       (y (ccl:%get-signed-long b)))
   (cond ((> x y) 1)
         ((< x y) -1)
         (t 0))))

(defun test-callbacks-with-qsort ()
 (ccl:%stack-block ((array 40))
   (loop for i from 0
         and n in '(7 2 10 4 3 5 1 6 9 8)
         do (setf (ccl:%get-signed-long array (* i 4)) n))
   (ccl:external-call "qsort" :address array :signed-int 10 :signed-int 4
                      :address qsort-callback :void)
   (loop for i from 0 below 10
         collect (ccl:%get-signed-long array (* i 4)))))

;; without the loop, the bug is not triggered
(loop repeat 10 collect (test-callbacks-with-qsort))

comment:3 Changed 10 years ago by gb

I can't reproduce this in either an up-to-date 1.3 or in the trunk.

There was a bug (fixed in r12008 in the trunk and r12012 in the 1.3 branch) that caused the eflags register to be restored incorrectly (restored to an essentially random value) on return from a callback; depending on what that random value was, this could either have been harmless or catastrophic. Whether or not this bug occurred depended on the alignment of the foreign (C) stack on entry to the callback.

FWIW, I couldn't reproduce this in the released 1.3 either, but that may not be conclusive.

If this crashes into the kernel debugger, I'd be interested in seeing the values of the machine registers (the output of the 'r' command in the kernel debugger), especially the value of %eflags.

Changed 10 years ago by codewitch

Backtrace and registers after qsort loop call.

comment:4 Changed 10 years ago by gb

The %eflags register in the transcript is bogus, so this looks like the bug that was fixed in r12008/r12012.

Please do an 'svn update' and recompile the lisp kernel if possible.

(Recompiling the lisp kernel is awkward for some Windows users; I checked in a binary a moment ago.)

comment:5 Changed 10 years ago by codewitch

  • Resolution set to fixed
  • Status changed from assigned to closed

After picking up the freshly checked in binary with svn update, Qsort and (cl-glut-examples:gears) both work!

Well done!! And thank you!

Note: See TracTickets for help on using tickets.