Comment 1 for bug 1133018

Just to clarify, this is not an sb-safepoint (= using safepoints) problem as such, but rather an sb-safepoint-strictly (= not having pseudo-atomic) problem, right?

The issue that was discussed on #sbcl being that the signal handler trampoline for this particular signal (the only asynchronous signal allowed to strike asynchronously during what used to be p/a) isn't careful enough at preventing the handler to be called when it's not appropriate to do so. (During GC? In a safepoint? Not clear. Need to find out.)

FWIW, stacktraces would be a nice first step towards fixing this.