fix invalid use of siglongjmp due to threads

[Bruno Haible]

Hi,

poke is a multi-threaded program. I see in gdb 3 threads from libgc:

(gdb) info threads 
  Id   Target Id         Frame 
* 1    Thread 0x7ffff7fc4700 (LWP 16429) "poke" 0x00007ffff727051d in read () 
at ../sysdeps/unix/syscall-template.S:84
  2    Thread 0x7ffff5ae2700 (LWP 16433) "poke" pthread_cond_wait@@GLIBC_2.3.2 
()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3    Thread 0x7ffff52e1700 (LWP 16434) "poke" pthread_cond_wait@@GLIBC_2.3.2 
()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  4    Thread 0x7ffff4ae0700 (LWP 16435) "poke" pthread_cond_wait@@GLIBC_2.3.2 
()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  5    Thread 0x7ffff42df700 (LWP 16436) "poke" 0x00007ffff6f935d3 in select () 
at ../sysdeps/unix/syscall-template.S:84
(gdb) where
#0  0x00007ffff727051d in read () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff7948a2d in rl_getc () from /lib/x86_64-linux-gnu/libreadline.so.6
#2  0x00000000004053db in poke_getc (stream=0x7ffff725a8e0 <_IO_2_1_stdin_>) at 
pk-repl.c:142
#3  0x00007ffff79492ad in rl_read_key () from 
/lib/x86_64-linux-gnu/libreadline.so.6
#4  0x00007ffff7932dd2 in readline_internal_char () from 
/lib/x86_64-linux-gnu/libreadline.so.6
#5  0x00007ffff7933545 in readline () from 
/lib/x86_64-linux-gnu/libreadline.so.6
#6  0x0000000000405878 in pk_repl () at pk-repl.c:313
#7  0x0000000000404d0c in main (argc=2, argv=0x7fffffffd808) at poke.c:683
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff5ae2700 (LWP 16433))]
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Datei oder 
Verzeichnis nicht gefunden.
(gdb) where   
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff7b87937 in GC_wait_marker () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#2  0x00007ffff7b7dc3a in GC_help_marker () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#3  0x00007ffff7b85ebc in GC_mark_thread () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#4  0x00007ffff72676ba in start_thread (arg=0x7ffff5ae2700) at 
pthread_create.c:333
#5  0x00007ffff6f9d41d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) thread 3
[Switching to thread 3 (Thread 0x7ffff52e1700 (LWP 16434))]
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     in ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
(gdb) where   
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff7b87937 in GC_wait_marker () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#2  0x00007ffff7b7dc3a in GC_help_marker () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#3  0x00007ffff7b85ebc in GC_mark_thread () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#4  0x00007ffff72676ba in start_thread (arg=0x7ffff52e1700) at 
pthread_create.c:333
#5  0x00007ffff6f9d41d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) thread 4
[Switching to thread 4 (Thread 0x7ffff4ae0700 (LWP 16435))]
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     in ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
(gdb) where   
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff7b87937 in GC_wait_marker () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#2  0x00007ffff7b7dc3a in GC_help_marker () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#3  0x00007ffff7b85ebc in GC_mark_thread () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#4  0x00007ffff72676ba in start_thread (arg=0x7ffff4ae0700) at 
pthread_create.c:333
#5  0x00007ffff6f9d41d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

And even if we soon won't use libgc any more, other libraries can create
threads at their own discretion. (E.g. macOS libc does this.)

But in a multithreaded program, any of the threads might get to execute any
signal handler. (Since you don't control the creation of the other threads,
and don't even have a way to enumerate them, you can't call pthread_sigmask
on them.)

In such a situation, siglongjmp may cause two threads to executed with the same
stack area. At moment the two stack pointers get close to each other, it's time
for Guru meditation.

This proposed patch fixes it.

The marker _GL_ASYNC_SAFE is purely for documentation purposes. See
gnulib-common.m4 for its (important) meaning.

Bruno

0001-Fix-invalid-use-of-siglongjmp-due-to-threads.patch
Description: Text Data