[Openmcl-devel] Exception in foreign context

[Gary Byers]

This probably isn't very helpful, but some months ago

On Sun, 13 Sep 2009, Patrick May wrote:

> On Sep 3, 2009, at 5:47 PM, Patrick May wrote:
>> On Sep 3, 2009, at 4:30 PM, R. Matthew Emerson wrote:
>>> On Sep 3, 2009, at 3:13 PM, Patrick May wrote:
>>>> 	I'm getting this error every couple of days when running
>>>> Hunchentoot
>>>> in CCL (1.3-r11936, 64 bit, Linux).  Any idea what's causing it?
>>>>
>>>> ? exception in foreign context
>>>> Exception occurred while executing foreign code
>>>> at create_exception_callback_frame + 80
>>>> ? for help
>>>>
>>>> [26583] Clozure CL kernel debugger: b
>>>> [26583] Clozure CL kernel debugger: current thread: tcr =
>>>> 0x7fe8ab2267b0, native thread ID = 0x11ec, interrupts disabled
>>>>
>>>>
>>>> (#x00007FE8ADBEDF48) #x0000300040018F7C : #<Function RECORD-SYSTEM-
>>>> LOCK #x0000300040018F2F> + 77
>>>> Bogus  frame 7fe8adbedf60
>>>> [26583] Clozure CL kernel debugger:
>>>
>>> Those symptoms don't remind me of any bug I know about right off
>>> hand.
>>>
>>> You might try updating your CCL, though.  You appear to be using the
>>> original 1.3 release binary, and I know that there have been
>>> important bug fixes to the 1.3 branch since release.
>>
>> 	Thanks for the quick response.  I've updated from Subversion and
>> rebuilt CCL to 1.3-r12755M.  Hopefully that will fix the problem.
>
> 	I just got the following problem.  I don't know if it's related to
> Clozure or to Hunchentoot (64-bit Linux):
> Welcome to Clozure Common Lisp Version 1.3-r12755M  (LinuxX8664)!
> ? STRING-OUTPUT-STREAM  #x300041AC43AD> is not of the expected
> tyexception in foreign context
> Exception occurred while executing foreign code
>  at create_exception_callback_frame + 80
> ? for help
> [5067] Clozure CL kernel debugger: ?
> (G)  Set specified GPR to new value
> (R)  Show raw GPR/SPR register values
> (L)  Show Lisp values of tagged registers
> (F)  Show FPU registers
> (S)  Find and describe symbol matching specified name
> (B)  Show backtrace
> (T)  Show info about current thread
> (X)  Exit from this debugger, asserting that any exception was handled
> (K)  Kill Clozure CL process
> (?)  Show this help
> [5067] Clozure CL kernel debugger: b
> current thread: tcr = 0x7fd6b38177b0, native thread ID = 0x1e96,
> interrupts disabled
>
>
> [5067] Clozure CL kernel debugger: t
> Current Thread Context Record (tcr) = 0x7fd6b38177b0
> Control (C) stack area:  low = 0x7fd6b35c4000, high = 0x7fd6b3818000
> Value (lisp) stack area: low = 0x7fd6b33a2000, high = 0x7fd6b35b3000
> Exception stack pointer = 0x7fd6b35c3788
> [5067] Clozure CL kernel debugger: k

Well, it's the same place that you were dying before, and the "t" command
output is actually helpful: it shows that the stack pointer is beyond
its bounds (e.g., the stack has overflowed.)  The particular point where
you're crashing is trying to push some information onto the lisp stack
so that it can call out to lisp code in response to an exception, and that's
faulting (suggesting that the lisp stack has overflowed as well.)

The very general kind of scenario that can cause this is:

   1) lisp code gets an exception
   2) a handler in the lisp kernel tries to figure out what happened and
      decides to call a lisp handler.
   3) The lisp handler gets an exception, and we repeat this process until
      stacks overflow.

>
> Any idea what could be causing this?

I've seen this happen, but wouldn't know how to make it happen if I wanted
to (short of intentionally redefining a lot of internal functions or running
with buggy lisp-level exception handlers installed.)  Something like:

? (defun foo (x y) (handler-case (/ x y) (division-by-zero () (foo x y))))
FOO
? (foo 1 0)

will signal a stack overflow before the stacks are completely exhausted,
and if you worked at it you might decide to handle that by calling (FOO 1 0)
again.



> Is anyone here running a website with Clozure and Hunchentoot?

We are, a few of our customers are, and I believe that many other people
are as well.  My understanding is that Hunchentoot depends on many other
CL packages and that finding the right versions of those packages can be
tricky; some people maintain web pages that try to help with this.  I don't
know the details, and I don't know if getting it wrong can somehow lead to
this sort of problem.

>
> Thanks,
>
> Patrick
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>