Inside a jail, programs that use pthread (libthr) get stuck in umtxn state. This problem exhibited itself since upgrading to 10.2-RELEASE-p5 with freebsd-update. Mitigations tried: - Updated poudriere jail and rebuilt all packages - Reinstalled all packages inside jail with pkg upgrade -f Test program: ---- CUT HERE ---- #include <unistd.h> #include <sys/types.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <string.h> void message(void *ptr); typedef struct stdata { int id; char msg[100]; } stdata; int main() { pthread_t t1, t2; stdata d1, d2; d1.id = 1; strcpy(d1.msg, "Thread 1"); d2.id = 2; strcpy(d2.msg, "Thread 2"); pthread_create(&t1, NULL, (void *)&message, (void *)&d1); pthread_create(&t2, NULL, (void *)&message, (void *)&d2); pthread_join(t1, NULL); pthread_join(t2, NULL); exit(0); } void message(void *ptr) { stdata *data; data = (stdata *) ptr; printf("Thread %d message %s \n", data->id, data->msg); pthread_exit(0); } ---- CUT HERE ---- Demonistration: $ cc -o pthread pthread.c -pthread $ ./pthread & [1] 45949 $ ps -aux | grep pthread ekollof 45949 0.0 0.0 14564 1708 5 SNJ 10:20AM 0:00.00 ./pthread $ procstat -kk 45949 PID TID COMM TDNAME KSTACK 45949 101151 pthread - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d umtxq_sleep+0x125 do_lock_umutex+0x1f74 __umtx_op_wait_umutex+0x78 amd64_syscall+0x357 Xfast_syscall+0xfb $ fg [1] + 45949 running ./pthread * I pressed Ctrl-T * load: 0.27 cmd: pthread 45949 [umtxn] 35.86r 0.00u 0.00s 0% 1692k * I pressed Ctrl-\ * ^\[1] + 45949 quit (core dumped) ./pthread
More people with the same problem can be found here: https://forums.freebsd.org/threads/issues-with-python-web-applications-in-jails.53440
(In reply to Emiel Kollof from comment #0) I cannot reproduce this on stable/10: pooma% stty tostop pooma% ./pr203765& [1] 62024 pooma% [1] + 62024 suspended (tty output) ./pr203765 pooma% fg [1] + 62024 continued ./pr203765 Thread 1 message Thread 1 Thread 2 message Thread 2 pooma% jobs pooma% Same when I tried the same sequence jailed. First question, can you reproduce the behavior on the host ? If no, compare the libc and libthr on the host and in the jail. Second question, if the behavior is reproducable on host, try, at least temporary, installing stable/10 kernel without touching the userland, and see if the issue is still there
Those indeed seemed to differ. I unpacked a base release tarball in the jail root (while excluding /etc and /var) and used freebsd-update to get it up to date. So, not a bug. Thanks for the effort.