Custom Query (1030 matches)

Historically, CCL has treated an exception that occurs in foreign code as being fatal; we don't in general know what foreign state may need to be unwound or whether the code that got the exception is reentrant, so the absolute best that we could do is a sort of "cross your fingers, pray, and signal a lisp error." Whether that's worth a try or not is a separate issue.

Relatively recent changes to the trunk allow us to note when SIGFPE is raised during execution of foreign code (at least on x8664); this is a good thing, in that it removes a little bit of overhead from every ff-call. This change exposes a subtle and long-standing bug.

When a thread gets an exception on Unix platforms, it stores the exception context in a TCR field, unmasks blocked signals, and waits for the exception lock. That makes sense if the exception occured during the execution of lisp code: if some other thread GCs while the thread in question is waiting, the GC thread will see that thread's pending exception context. If the exception occurs in foreign code, the GC thread should not see the pending exception context. (As I said, this is a longstanding bug; the SIGFPE handling just makes it theoretically more likely to occur.)

On Win64, a thread can be suspended or interrupted while in the process of returning from an exception and restoring its valence. We've assumed that a thread can only return from an exception if the exception occurred during execution of lisp code, so when pc-lusering our way out of exception return on Win64 we've assumed that we'll be resuming in lisp state; the SIGFPE handing in foreign code means that that assumption isn't valid, and we'll need to handle this more carefully.

The likelyhood of bad things happening is small (but non-zero.)

Our busy server (6 processes pulling and parsing XML feeds plus Hunchentoot serving web pages), got an infinite loop while interning a string.

We've seen this only once after a week of running this code 24/7, so it's likely hard to reproduce.

(lisp-implementation-version)
"Version 1.5-r13695M  (LinuxX8664)"

Relevant code:

(defun make-weak-hash-table (&rest rest)
  (declare (dynamic-extent rest))
  #-ccl                                                                         
  (apply #'make-hash-table rest)
  #+ccl
  (apply #'make-hash-table :weak :value rest))

(defvar *equal-object-hash*
  (make-weak-hash-table :test 'equal))

(defun equal-object-p (object)
  (or (stringp object)
      (and (numberp object) (not (fixnump object)))))

(defun intern-equal-object (object)
  (cond ((equal-object-p object)
         (or (gethash object *equal-object-hash*)
             (setf (gethash object *equal-object-hash*) object)))
        (t object)))

Error: Stack overflow: "CCL has entered the kernel debugger, due to an exception 11"

Backtrace:

(#x00007F7502647CA0) #x00003000000B2294 : #<Function LOCK-FREE-COUNT-ENTRIES #x00003000000B220F> + 133
(#x00007F7502647CE8) #x00003000000B2F9C : #<Function %LOCK-FREE-REHASH #x00003000000B2F0F> + 141
(#x00007F7502647D40) #x00003000000B29F4 : #<Function LOCK-FREE-REHASH #x00003000000B291F> + 213
(#x00007F7502647D80) #x00003000000B2294 : #<Function LOCK-FREE-COUNT-ENTRIES #x00003000000B220F> + 133
(#x00007F7502647DC8) #x00003000000B2F9C : #<Function %LOCK-FREE-REHASH #x00003000000B2F0F> + 141
(#x00007F7502647E20) #x00003000000B29F4 : #<Function LOCK-FREE-REHASH #x00003000000B291F> + 213
(#x00007F7502647E60) #x00003000000B2294 : #<Function LOCK-FREE-COUNT-ENTRIES #x00003000000B220F> + 133
(#x00007F7502647EA8) #x00003000000B2F9C : #<Function %LOCK-FREE-REHASH #x00003000000B2F0F> + 141
(#x00007F7502647F00) #x00003000000B29F4 : #<Function LOCK-FREE-REHASH #x00003000000B291F> + 213
(#x00007F7502647F40) #x00003000000B2294 : #<Function LOCK-FREE-COUNT-ENTRIES #x00003000000B220F> + 133
[...]
(#x00007F7502655680) #x00003000000960B4 : #<Function GETHASH #x0000300000095E4F> + 613
(#x00007F75026556D0) #x000030200297F85C : #<Function INTERN-EQUAL-OBJECT #x000030200297F7CF> + 141
(#x00007F75026556E8) #x0000302002B0659C : #<Function (:INTERNAL BUILD-FN12015 BWIN-XML-PARSER) #x0000302002B0654F> + 77
(#x00007F7502655748) #x0000302002A09714 : #<Function MAYBE-BUILD-GAME-INTERNAL #x0000302002A096AF> + 101
(#x00007F7502655780) #x0000302002B07974 : #<Function (:INTERNAL ***-XML-PARSER) #x0000302002B0750F> + 1125
(#x00007F7502655828) #x0000302002A8D9FC : #<Function DOM-TRAVERSAL-HELPER #x0000302002A8D80F> + 493
(#x00007F7502655888) #x0000302002A8E1AC : #<Function DOM-TRAVERSAL-HELPER #x0000302002A8D80F> + 2461
(#x00007F7502655948) #x0000302002A8E1AC : #<Function DOM-TRAVERSAL-HELPER #x0000302002A8D80F> + 2461
(#x00007F7502655A08) #x0000302002A8E1AC : #<Function DOM-TRAVERSAL-HELPER #x0000302002A8D80F> + 2461
(#x00007F7502655AC8) #x0000302002A8C9FC : #<Function DOM-TRAVERSAL #x0000302002A8C82F> + 461
(#x00007F7502655B60) #x0000302002A04A04 : #<Function PROCESS-FEED-INTERNAL #x0000302002A043BF> + 1605
(#x00007F7502655C30) #x0000302002A05D04 : #<Function PROCESS-FEED #x0000302002A05A6F> + 661
(#x00007F7502655CB0) #x00003020029FC43C : #<Function (:INTERNAL PROCESS-NEXT-FEED) #x00003020029FB7AF> + 3213
(#x00007F7502655D50) #x0000302002414C24 : #<Function (:INTERNAL MAKE-TASK) #x000030200241471F> + 1285
(#x00007F7502655DE8) #x000030200240BE3C : #<Function (:INTERNAL NEW-WORKER-THREAD) #x000030200240BADF> + 861
(#x00007F7502655E68) #x0000302000F1EFDC : #<Function (:INTERNAL BINDING-DEFAULT-SPECIALS) #x0000302000F1ECBF> + 797
(#x00007F7502655EB0) #x00003000004718E4 : #<Function RUN-PROCESS-INITIAL-FORM #x000030000047160F> + 725
(#x00007F7502655F48) #x0000300000472204 : #<Function (:INTERNAL (%PROCESS-PRESET-INTERNAL (PROCESS))) #x000030000047207F> + 389
(#x00007F7502655F98) #x000030000044F66C : #<Function (:INTERNAL THREAD-MAKE-STARTUP-FUNCTION) #x000030000044F53F> + 301

Building Clozure CL from sources using the standard procedure on Windows 7 64-bit (msys/mingw-w4) fails with:

Error: File exists : "c:/Docume~1/gdr/" While executing: CREATE-DIRECTORY, in process listener(1).