Public bug reported:
The following program (also attached) deadlocks when run under QEMU user
on Linux.
#include
#include
#include
#include
#include
#include
#define NUM_THREADS 100
#define NUM_FORKS 10
pthread_barrier_t barrier;
void *t(void *arg) {
for (int i = 0; i < NUM_FORKS; i++) {
pid_t pid = fork();
if (pid < 0)
abort();
if (!pid)
_exit(0);
if (waitpid(pid, NULL, 0) < 0)
abort();
}
//pthread_barrier_wait();
return NULL;
}
int main(void) {
pthread_barrier_init(, NULL, NUM_THREADS);
pthread_t ts[NUM_THREADS];
for (size_t i = 0; i < NUM_THREADS; i++) {
if (pthread_create([i], NULL, t, NULL))
abort();
}
for (size_t i = 0; i < NUM_THREADS; i++) {
pthread_join(ts[i], NULL);
}
printf("Done: %d\n", getpid());
return 0;
}
To reproduce:
$ gcc test.c -pthread
$ while qemu-x86_64 ./a.out; do :; done
(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child).
Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks.
With the values above it often deadlocks on the first try on my machine.
When it deadlocks, there is a child qemu process with two threads which
is waited upon by one of the worker threads of the parent.
I tried to avoid the deadlock by serializing fork() with a mutex, but it
didn't help. However, ensuring that no thread exits until all forks are
done (by adding a barrier to t()) does seem to help, at least, the
program above could run for a half an hour until I terminated it.
Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-
user targets.
** Affects: qemu
Importance: Undecided
Status: New
** Attachment added: "test.c"
https://bugs.launchpad.net/bugs/1887306/+attachment/5392123/+files/test.c
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1887306
Title:
qemu-user deadlocks when forked in a multithreaded process
Status in QEMU:
New
Bug description:
The following program (also attached) deadlocks when run under QEMU
user on Linux.
#include
#include
#include
#include
#include
#include
#define NUM_THREADS 100
#define NUM_FORKS 10
pthread_barrier_t barrier;
void *t(void *arg) {
for (int i = 0; i < NUM_FORKS; i++) {
pid_t pid = fork();
if (pid < 0)
abort();
if (!pid)
_exit(0);
if (waitpid(pid, NULL, 0) < 0)
abort();
}
//pthread_barrier_wait();
return NULL;
}
int main(void) {
pthread_barrier_init(, NULL, NUM_THREADS);
pthread_t ts[NUM_THREADS];
for (size_t i = 0; i < NUM_THREADS; i++) {
if (pthread_create([i], NULL, t, NULL))
abort();
}
for (size_t i = 0; i < NUM_THREADS; i++) {
pthread_join(ts[i], NULL);
}
printf("Done: %d\n", getpid());
return 0;
}
To reproduce:
$ gcc test.c -pthread
$ while qemu-x86_64 ./a.out; do :; done
(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child).
Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks.
With the values above it often deadlocks on the first try on my
machine. When it deadlocks, there is a child qemu process with two
threads which is waited upon by one of the worker threads of the
parent.
I tried to avoid the deadlock by serializing fork() with a mutex, but
it didn't help. However, ensuring that no thread exits until all forks
are done (by adding a barrier to t()) does seem to help, at least, the
program above could run for a half an hour until I terminated it.
Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-
user targets.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1887306/+subscriptions
