Hi Eric, Thanks for this patch.
> When compiling for platforms like Solaris where c-stack has determined > HAVE_XSI_STACK_OVERFLOW_HEURISTIC, the use of libsigsegv just bloats the > application, since c-stack was already sufficient. Agreed. > Should I also add lib-ignore to the > dependencies of c-stack, so that Solaris need not waste space if > libsigsegv is not used independently of c-stack? Please not. lib-ignore causes a whole lot of warnings to be output each time a program is linked, on many platforms. If you want to save linking with libsigsegv, just do the test '#if HAVE_LIBSIGSEGV && ! HAVE_XSI_STACK_OVERFLOW_HEURISTIC' at configure time rather than at compile-time, create two new variables LIBCSTACK and LTLIBCSTACK, AC_SUBST them, and document in modudes/c-stack that the appropriate of these two variables needs to be used while linking. > In writing the patch, I noticed that it is probably not portable to > longjmp out of a stack overflow handler This is not an issue with the current uses of c-stack, which just print a message and call _exit in the handler. In general, longjmping out of a stack overflow handler can be done provided that you call sigsegv_leave_handler() before. This is a function from libsigsegv that does the necessary magic. It has been tested in GNU clisp: when the user types Ctrl-C and then 'abort' to get to the top-level interactive prompt, this code is exercised. > the stack overflow might have occurred > in the middle of a library function like malloc; even though you can > manage to get back to the original stack, you no longer have guarantees > that malloc will work. So, we either need to document this in the > contract of c_stack_action Yes, this must be documented. There's nothing you can do about it. > or we need to add a function in c-stack.h that > the user must call before attempting longjmp anyway; this wrapper would be > responsible for calling libsigsegv's sigsegv_leave_handler as needed. There's a misunderstanding here: sigsegv_leave_handler() does only ensure that the thread - viewed from the kernel's point of view - is in a reasonable state; it does *not* repair any interrupted stateful library function like malloc. (In GNU clisp this is not a problem in practice, because malloc is rarely called.) Another thing: Could you please add a comment summarizing our discussions from 2008-06-06, namely explaining why - although Linux and Solaris both have a working sigaltstack(), SIGINFO, and si_addr - HAVE_XSI_STACK_OVERFLOW_HEURISTIC is only defined on Solaris and not on Linux? Bruno
