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
48
49
50
51
52
53
54
55
56
57
|
<think>
Okay, so I need to figure out what category this bug falls into. The user is having issues when building Go code inside a Docker container using qemu-ppc64le-static. The problem occurs when running multi-threaded commands like 'go build', which sometimes hang or result in segfaults.
Let me break down the information provided:
1. **Environment**: They're using QEMU for ppc64le architecture, built statically and run within a Docker container. The host is an Intel i7 with multiple cores.
2. **Steps to Reproduce**:
- Built QEMU as static.
- Created a Go project with a simple 'hello.go'.
- Used a Dockerfile to set up the environment.
- When running 'go build', it fails with segfaults or hangs, but works when using single-threaded mode.
3. **Error Details**:
- The error involves SIGSEGV (segmentation violation) in Go's runtime.
- Specifically mentions issues during runtime execution and panic due to unexpected signals.
- It also references 'runtime.stopm' which is related to thread management in Go.
4. **Observations**:
- Single-threaded builds work fine, implying that the issue arises with concurrency.
- Similar problems have been reported with multi-threaded apps under QEMU.
Now, considering possible categories:
- **Instruction**: Faulty instructions. But the error seems more systemic than a specific instruction failure.
- **Syscall**: Errors related to system calls. The issue involves syscalls (like Syscall6) and segmentation faults, which could be syscall-related.
- **Runtime**: Other runtime errors. Since it's happening in Go's runtime during multi-threaded execution.
The error occurs when the Go runtime is handling concurrency, specifically in 'runtime.stopm', which suggests it's a problem within the Go runtime itself or how QEMU emulates the environment for concurrent processes.
But considering the user thinks it might not be a Go issue and relates to QEMU running multi-threaded apps, perhaps it's more about how QEMU handles syscalls or concurrency. However, the error message points to Go's runtime stack with Syscall6, suggesting a problem during system calls made by the Go process.
Alternatively, since the problem occurs under QEMU when multiple threads are involved, maybe it's an issue with how QEMU emulates the ppc64le architecture for syscalls in multi-threaded contexts. But the error message specifically points to Go's runtime, which makes me think it might be a runtime issue rather than a syscall or instruction problem.
However, given that similar issues are reported with other applications under QEMU, and considering the environment is emulated, perhaps it's more about how syscalls are handled in QEMU when multiple threads are involved. But I'm not entirely sure if this falls under 'syscall' category since the issue arises within Go's runtime.
But looking back at the possible categories: instruction, syscall, runtime. Since the error occurs during a system call (Syscall6) and involves concurrency which can complicate system calls in an emulated environment, it might be related to syscalls not handling multi-threading correctly under QEMU.
However, since the user is using Go and the issue arises within Go's runtime when building, perhaps it's more about how the runtime interacts with the emulated environment. But given that other applications have similar issues, I think it points towards a problem in QEMU's handling of syscalls or concurrency.
Wait, but the user says they built qemu from upstream master and see the same issue on arm64 as well. So maybe it's a more general QEMU issue with multi-threaded apps across different architectures.
But for classification purposes, the error is in Go's runtime stack during a syscall, so perhaps it's under 'syscall'. Alternatively, if it's an internal Go runtime issue triggered by QEMU's environment, it might be 'runtime'.
But given that similar issues are reported against QEMU with multi-threaded applications, I think it's more about how syscalls or concurrency is handled in the emulated environment. So perhaps it's a 'syscall' issue.
However, since the error message mentions unexpected signals during runtime execution and panic in the Go runtime, maybe it's better classified under 'runtime'.
But I'm not entirely certain. Maybe looking at other bug reports: issues with segfaults and concurrency often point to problems in how the emulator handles system calls or threading. Alternatively, if it's Go-specific, then it's a runtime issue.
In this case, since the problem occurs when using multi-threaded Go builds under QEMU, and the error is during a syscall (Syscall6), I think it's more likely related to 'syscall' handling in the emulator.
</think>
The bug report involves issues with syscalls failing in a multi-threaded environment within QEMU. The segmentation fault occurs during a system call, suggesting problems with how QEMU handles syscalls when multiple threads are involved.
**Answer:**
syscall
|