Bug 203765 - Processes inside jail that use libthr get stuck in 'umtxn' state.
Summary: Processes inside jail that use libthr get stuck in 'umtxn' state.
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: threads (show other bugs)
Version: 10.2-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-threads (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-14 09:01 UTC by Emiel Kollof
Modified: 2015-10-19 23:09 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emiel Kollof 2015-10-14 09:01:22 UTC
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
Comment 1 Emiel Kollof 2015-10-14 09:05:54 UTC
More people with the same problem can be found here:

https://forums.freebsd.org/threads/issues-with-python-web-applications-in-jails.53440
Comment 2 Konstantin Belousov freebsd_committer freebsd_triage 2015-10-14 10:10:19 UTC
(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
Comment 3 Emiel Kollof 2015-10-16 12:05:00 UTC
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.