Ticket #715 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

Foreign exception issues

Reported by: gb Owned by:
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: trunk
Keywords: Cc:


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.)

Change History

comment:1 Changed 3 years ago by gb

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

r14426 and r14427 try to address this on x8664 unix systems. r14425 backs out of the new ffcall/FP exception stuff on Win64, since it doesn't seem that it can work there.

comment:2 Changed 3 years ago by rme

(In [14433]) Merge r14425 through r14432 from trunk.


  • foreign FPE handling (see ticket:776 and ticket:715)
  • %get-xcf-byte on x8632 (r14428)
  • make IDE "open selection" slightly smarter (r14429)
  • ensure advapi32.dll is loaded on 64-bit Windows (r14431)
  • Windows shared library improvements (r14432)
Note: See TracTickets for help on using tickets.