Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34

[Paul Eggert <eggert@cs.ucla.edu>]

On 5/22/21 3:59 PM, Bruno Haible wrote:

> Now, you are arguing "let's ignore whether programs use nested functions".

Not at all. All I'm saying is, stack-overflow handlers shouldn't call 
via pointers to nested functions.

There are already several restrictions on stack-overflow handlers; for 
example, you can't call 'exit'. A restriction against calling via 
pointers to nested functions is just another restriction - one that's 
easier to comply with than the 'exit' restriction, in my experience.

If stack-overflow handlers absolutely can't live without calling via 
pointers to nested functions, one can work around the problem by 
compiling with gcc -fno-trampolines. However, I don't recommend this - 
just as there are a lot of other common features that I don't recommend 
in stack-overflow handlers, such as recursion.

> It adds complexity to the calling program. The developer has to check whether
> their code uses nested functions.

Not all code, just stack-overflow handlers. It should be reasonable to 
ask developers to do that, as stack-overflow handlers should be simple 
and easy to audit anyway.


>    - The current POSIX specifies a constant SIGSTKSZ,
>    - Eric Blake is proposing that POSIX drops the constant-ness, and that
>      SIGSTKSZ becomes a macro that merely expands to an expression. [2]

It's more than that. glibc has already changed to drop the 
constant-ness. Gnulib should of course be portable to POSIX, but it's 
even more important for Gnulib to be portable to GNU.

> being close to POSIX would mean to use SIGSTKSZ for the allocation
> of an alternate stack, most likely through malloc.

That would also be a reasonable change to the test cases. I didn't do 
that, partly because I thought it simpler just to allocate an enormous 
alternate signal stack, partly because I wasn't yet entirely clear on 
exactly when malloc is bad for allocating alternate signal stacks so I 
wanted to avoid malloc entirely. But if you'd prefer that the test cases 
use malloc I can rewrite them to do that.

> it would have been more maintainable to write
> 
>    /* SIGSTKSZ can no longer be guaranteed to be a constant.  Until POSIX
>       clarifies it, use a large constant anyway.  */
>    #undef SIGSTKSZ
>    #define SIGSTKSZ (1 << 24)

The code I wrote attempted to do the right thing even on (hypothetical) 
platforms where MINSIGSTKSZ exceeds 1<<24. A simple #undef/#define 
wouldn't do that. Again, using malloc should fix this issue in a less 
hoggish way.

> 3) The approach you used now, to use a 16 MB space for sigaltstack(),
> is not portable to multithreaded situations. For example, I have a test
> program (attached) that I consider to add as a unit test to gnulib.
> It uses stack space from the thread itself as alternate signal stack.
> That is a perfectly natural thing to do, because
>    - the permissions of the alternate stack are automatically right,
>    - this alternate stack gets deallocated automatically when the thread
>      dies (no memory leak).
> But allocating 16 MB on a thread's stack is not portable. On Solaris/SPARC,
> the main thread's size is only 8 MB.

The code I wrote didn't have to (and didn't) attempt to address this 
scenario. For something like that, have you looked at Florian Weimer's 
recent <sys/cstack.h> proposal for glibc 
<https://sourceware.org/pipermail/libc-alpha/2021-May/126605.html>? If 
that API is added to glibc and can be simulated by Gnulib well-enough on 
other platforms, that should be a good way to address the problem that 
you mention.