Steel Bank Common Lisp

Thomas Bakketun wrote:
> I'm experiencing crashes with SBCL on FreeBSD. SBCL drops into the LDB
> with the message "Signal 13 masked". The application is a multi threaded
> mod_lisp based web server application. I have experienced the crash on
> FreeBSD 6.3 with SBCL 1.0.27 and on FreeBSD 7.2 with SBCL 1.0.30.

Have you tried this on other platforms?


> Below is an example of a crash. Every crash happens in the same spot
> with a very similar backtrace. As signal 13 is SIGPIPE, it's quite
> obvious that this bug is somehow triggered by trying to write a reply to
> closed connection. Unfortunately I haven't been able find a predictable
> way to reproduce this crash yet.

Are you using WITH(OUT)-INTERRUPTS somewhere? Have you or some lib you
are using set up signal handlers for SIGPIPE?

  Leslie

-- 
http://www.linkedin.com/in/polzer

On Miércoles 16 Septiembre 2009, Thomas Bakketun wrote:
> I'm experiencing crashes with SBCL on FreeBSD. SBCL drops into the
> LDB with the message "Signal 13 masked". The application is a multi
> threaded mod_lisp based web server application. I have experienced
> the crash on FreeBSD 6.3 with SBCL 1.0.27 and on FreeBSD 7.2 with
> SBCL 1.0.30.
>
> Below is an example of a crash. Every crash happens in the same spot
> with a very similar backtrace. As signal 13 is SIGPIPE, it's quite
> obvious that this bug is somehow triggered by trying to write a reply
> to closed connection. Unfortunately I haven't been able find a
> predictable way to reproduce this crash yet.
>
> Any ideas of what might cause this problem?
>
>
>
> * Signal 13 masked
> fatal error encountered in SBCL pid 94897(tid 673190768):
> some blockable signals blocked, some unblocked
>
>
> Welcome to LDB, a low-level debugger for the Lisp runtime
> environment.
>
> ldb> backtrace
> Backtrace:
> 0: Foreign function monitor_or_something, fp = 0x2947f178, ra =
> 0x8057b9e 1: Foreign function ldb_monitor, fp = 0x2947f2e8, ra =
> 0x8057893 2: Foreign function monitor_or_something, fp = 0x2947f2f8,
> ra = 0x80578db 3: Foreign function lose, fp = 0x2947f328, ra =
> 0x8054bf5
> 4: Foreign function all_signals_blocked_p, fp = 0x2947f358, ra =
> 0x8055a1b 5: Foreign function blockables_blocked_p, fp = 0x2947f378,
> ra = 0x8055c61 6: Foreign function check_blockables_blocked_or_lose,
> fp = 0x2947f388, ra = 0x8055c81
> 7: Foreign function maybe_defer_handler, fp = 0x2947f3a8, ra =
> 0x8056107
> 8: Foreign function 
> unblock_signals_in_context_and_maybe_warn, fp = 0x2947f3d8, ra =
> 0x80566ab

unblock_signals_in_context_and_maybe_warn is called in four cases:
1) the control stack is exhausted
2) the binding stack is exhausted
3) the alien stack is exhausted
4) a memory fault is encountered

In all cases the call to u_s_i_c_a_m_w is preceded by an fprintf to 
stderr: "INFO control/binding/alien stack guard page unprotected" or a 
corruption warning. Unless I overlooked something the output to stderr 
is missing.

Cheers, Gabor

Gábor Melis wrote:
> unblock_signals_in_context_and_maybe_warn is called in four cases:
> 1) the control stack is exhausted
> 2) the binding stack is exhausted
> 3) the alien stack is exhausted
> 4) a memory fault is encountered
> 
> In all cases the call to u_s_i_c_a_m_w is preceded by an fprintf to 
> stderr: "INFO control/binding/alien stack guard page unprotected" or a 
> corruption warning. Unless I overlooked something the output to stderr 
> is missing.

The output should be complete. To be sure I ran the application without 
any wrappers (detachtty and rc-scripts), but no more messages is printed 
when it crashes.