qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]