Re: [Sbcl-devel] Bad libraries and signals

[Daniel B. <da...@te...>]

Christophe Rhodes <cs...@ca...> writes:

> It turns out that SBCL doesn't like being linked against the current
> releases of SDL libraries, because these libraries clobber our signal
> handlers, by putting them back in handler, not action, mode (by which
> I mean the signal handler only receives one argument from the kernel,
> not the three that we require).
[...]
>   void sigsegv_handler(int signum, siginfo_t *info, void *data) {
>       if (info == NULL
> #if !(LISP_FEATURE_SPARC && LISP_FEATURE_LINUX) /* KLUDGE */
>           || data == NULL
> #endif
> )
>           lose("Someone has probably trashed our signal handlers.");
>       ... }
>
> but, on the x86, this isn't going to work, because, as we have
> established through pain and suffering, SIGSTKSZ isn't enough stack
> space to call printf().

I rather suspect that in practice it will turn out to work after all,
because SA_ONSTACK is a sigaction flag just like SA_SIGINFO, and if
they're trashing one they probably trash the other too ...

> Any suggestions?  Changing the sigaltstack stuff to use something like
> SIGSTKSZ*16 will probably work, but seems a trifle inelegant -- is
> there anything better?

I think this will probably be a good idea anyway, though.  Define
something in the $arch-$os-os.h file with our experimentally
determined signal stack sizes.  As a bonus side-effect, we could give
it a name that doesn't suffer from ENVWLS


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources