blob: 0db5c5cf9d332c5facae664d248ec7b68ae8bb8c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
other: 0.261
semantic: 0.194
device: 0.065
performance: 0.064
files: 0.061
vnc: 0.061
network: 0.052
graphic: 0.043
permissions: 0.040
PID: 0.038
boot: 0.036
debug: 0.033
socket: 0.032
KVM: 0.021
debug: 0.435
other: 0.128
files: 0.103
PID: 0.070
semantic: 0.056
performance: 0.044
network: 0.037
device: 0.028
graphic: 0.021
boot: 0.019
socket: 0.018
KVM: 0.015
permissions: 0.015
vnc: 0.013
App-level clone emulation for microblaze is broken
When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack.
I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem.
I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines.
Here is a minimal test case showing the problem.
I accidentally posted the patch, which is here, on the wrong bug report (1068900 instead of here). Apologies. For reference here is the patch; it was committed and fixes this issue:
https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html
Issue # 1068900, where I mistakenly posted the patch, is unrelated and not fixed; it should be reopened and this issue (1066909) should be marked fixed.
|