multithreading not working right under qemu user mode for sh4
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
In a multithreaded program running under qemu-sh4 (version 2.9.0), thread termination and/or pthread_join is not working right.
The attached program works natively on all kinds of platforms, and under qemu user mode emulation for at least alpha, armelhf, aarch64, powerpc64le.
How to reproduce:
- Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -lpthread -o test-tls test-tls.c
- Set environment variables for running qemu-sh4.
- ~/inst-
Expected behaviour: After the "Worker xxxxx dying" line, the main() function prints "OK", and the program terminates.
Actual behaviour (only on sh4): After the "Worker xxxxx dying" line, it hangs. Attaching gdb to qemu shows 15 threads with a stack trace like
#0 safe_syscall_base () at /build/
#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=128, val=val@entry=2, timeout=<optimized out>, uaddr2=
val3=
#2 0x00005584f870353b in do_futex (val3=-161181992, uaddr2=4134624624, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>)
at /build/
#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-160342672,
arg6=
#4 0x00005584f86f454a in cpu_loop (env=env@
#5 0x00005584f86f5dd5 in clone_func (arg=0x7fff4d48
#6 0x00007f08f05a46ba in start_thread (arg=0x7f08f136
#7 0x00007f08f02da3dd in clone () at ../sysdeps/
and 1 thread with a stack trace like
#0 safe_syscall_base () at /build/
#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=0, val=val@
val3=
#2 0x00005584f870353b in do_futex (val3=-161180376, uaddr2=4135101768, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>)
at /build/
#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-159865528,
arg6=
#4 0x00005584f86f454a in cpu_loop (env=0x5584fb3b
#5 0x00005584f86c12d3 in main (argc=<optimized out>, argv=0x7fff4d48
at /build/
and 1 thread with a stack trace like
#0 syscall () at ../sysdeps/
#1 0x00005584f876eab5 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /build/
#2 qemu_event_wait (ev=ev@
#3 0x00005584f87748ce in call_rcu_thread (opaque=<optimized out>) at /build/
#4 0x00007f08f05a46ba in start_thread (arg=0x7f08eff6
#5 0x00007f08f02da3dd in clone () at ../sysdeps/
Another gnulib test (test-lock) fails with an assertion inside glibc: mutex_lock. c:81: __pthread_ mutex_lock: Assertion `mutex- >__data. __owner == 0' failed.
test-lock: pthread_
qemu: uncaught target signal 6 (Aborted) - core dumped
Based on this, I would speculate that the problem is in the qemu emulation of the Linux system calls that glibc uses for multithreading or in the implementation of the primitives used by qemu_event_wait().