1 files changed, 112 insertions, 0 deletions
diff --git a/results/classifier/108/other/1887306 b/results/classifier/108/other/1887306
new file mode 100644
index 000000000..49d6432be
--- /dev/null
+++ b/results/classifier/108/other/1887306
@@ -0,0 +1,112 @@
+other: 0.926
+graphic: 0.923
+semantic: 0.901
+performance: 0.900
+debug: 0.895
+permissions: 0.879
+socket: 0.828
+PID: 0.827
+device: 0.810
+boot: 0.799
+files: 0.798
+network: 0.791
+vnc: 0.746
+KVM: 0.742
+
+qemu-user deadlocks when forked in a multithreaded process
+
+The following program (also attached) deadlocks when run under QEMU user on Linux. 
+
+#include <pthread.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <unistd.h>
+
+#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(&barrier);
+    return NULL;
+}
+
+int main(void) {
+    pthread_barrier_init(&barrier, NULL, NUM_THREADS);
+    pthread_t ts[NUM_THREADS];
+    for (size_t i = 0; i < NUM_THREADS; i++) {
+        if (pthread_create(&ts[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.
+
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+Still reproduces with QEMU 6.0.0.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/358
+
+