Custom Query (1030 matches)

As of r7528 there is a bug in incremental search, which can usually be triggered by doing wrapping incremental search, back and forward a few times and then exiting it and perhaps clicking the mouse. This here is NOT a bug report about that bug. But when you do hit that bug, you get an error about NIL not being a structure, and the lisp craps out trying to show the backtrace.

I've had it happen one of two ways: sometimes it gets an exception and enters the kernel debugger. Other times it still seems to get an exception, but somehow manages to handle it and prints some backtraces about the error within the error. In the second case, you can actually just kill the window that caused the problem, and continue with the same lisp. In the first case, the lisp is hosed.

I've attached terminal output for both cases.

(This is assuming ccl::conditional-store should work as a typical compare-and-swap, even though it's not exported.)

The RUN function below causes an assertion failure within 2000 iterations on my Linux-x86 machine. An svref place has the same issue. I did not see a problem on Darwin.

Removing the assertion (but keeping the conditional-store) results in a hang. Replacing that conditional-store (the second one) with setf also produces a hang.

(defstruct stack
  (head nil)
  (lock nil))

(defun call-with-spin-lock (stack fn)
  (loop :until (ccl::conditional-store
                (stack-lock stack) nil t))
  (unwind-protect
       (funcall fn)
    (assert (ccl::conditional-store
             (stack-lock stack) t nil))))

(defmacro with-spin-lock ((stack) &body body)
  `(call-with-spin-lock ,stack (lambda () ,@body)))

(defun push-stack (value stack)
  (with-spin-lock (stack)
    (push value (stack-head stack))))

(defun pop-stack (stack)
  (with-spin-lock (stack)
    (pop (stack-head stack))))

(defun test (thread-count)
  (let ((stack (make-stack)))
    (loop :repeat thread-count
          :do (ccl:process-run-function "test" #'push-stack t stack))
    (loop :repeat thread-count
          :do (loop :until (pop-stack stack)))))

(defun run ()
  (loop
     (test 1)
     (format t ".")))

On at least some fairly recent versions of OSX, using drag-and-drop to drag text around in the Cocoa IDE generates an FP exception (invalid operation IIRC). This happens deep in some CG text-drawing code that's invoked by CCL calling the superclass's #/mouseDown: method, and we report it as an arithmetic error. The error's likely to just be confusing and disruptive to the user.

We can work around this particular bug by disabling FP exceptions around the next-method call.

We generally try to report FP exceptions that occur in foreign code; this certainly makes sense if (for instance) #_sin is called as part of the implementation of CL:SIN. It's less clear that it's desirable or useful to try to detect and report FP exceptions that have nothing to do with CL math functions, though we've traditionally done so.