[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1907969] Re: linux-user/i386: Segfault when mixing threads and sign
From: |
The Lemon Man |
Subject: |
[Bug 1907969] Re: linux-user/i386: Segfault when mixing threads and signals |
Date: |
Wed, 16 Dec 2020 08:59:30 -0000 |
I finally understand where the problem is.
Qemu's user-mode emulation maps guest threads to native ones by spawning a new
native one
and running a forked copy of the CPUX86State in parallel with the main thread.
This works fine for pretty much every architecture but i386 where the GDT/LDT
comes into
play: the two descriptor tables are shared among all the threads, mimicking the
real hw
behaviour, but since no host task-switching is being performed the TLS entry in
the GDT
become stale.
Raising a signal makes Qemu reload the GS segment from the GDT, that's why
removing that
line makes the problem disappear.
The problem is also confined to musl libc because of an interesting
implementation choice.
Once a thread dies Glibc adds the now unused stack to a queue in order to reuse
it later,
while musl frees it right away when it's not needed anymore and, as a
consequence, makes
Qemu segfault.
As luck has it, after spending too much time debugging this, I found somebody
else already
stumbled across this problem and wrote a patch.
https://patchew.org/QEMU/74c9f1d9-4497-31c2-34a7-e21bef7932bd@scieneer.com/mbox
Too bad the patch flew under the radar...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1907969
Title:
linux-user/i386: Segfault when mixing threads and signals
Status in QEMU:
New
Bug description:
Given the following C program, qemu-i386 will surely and certainly segfault
when executing it.
The problem is only noticeable if the program is statically linked to musl's
libc and, as written
in the title, it only manifests when targeting i386.
Removing the pthread calls or the second raise() makes it not
segfault.
The crash is in some part of the TCG-generated code, right when it tries to
perform a
%gs-relative access.
If you want a quick way of cross-compiling this binary:
* Download a copy of the Zig compiler from https://ziglang.org/download/
* Compile it with
`zig cc -target i386-linux-musl <C-FILE> -o <OUT>`
```
#include <pthread.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>
#include <asm/prctl.h>
#include <sys/syscall.h>
void sig_func(int sig)
{
write(1, "hi!\n", strlen("hi!\n"));
}
void func(void *p) { }
typedef void *(*F)(void *);
int main()
{
pthread_t tid;
struct sigaction action;
action.sa_flags = 0;
action.sa_handler = sig_func;
if (sigaction(SIGUSR1, &action, NULL) == -1) {
return 1;
}
// This works.
raise(SIGUSR1);
pthread_create(&tid, NULL, (F)func, NULL);
pthread_join(tid, NULL);
// This makes qemu segfault.
raise(SIGUSR1);
}
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907969/+subscriptions