[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34
Date: Sat, 22 May 2021 22:12:22 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]