blob: eac4271993dbdc1ba26569c7eec73aa898fefc2a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Alright, let me try to figure out how to classify this bug report. So, the issue is about Chrome-based apps not running under QEMU user mode. The problem occurs when Chrome tries to fork a render process using `/proc/self/exe`. The provided code example shows that it fails with "qemu: unknown option 'type=renderer'".
From what I understand, Chrome uses `/proc/self/exe` to determine the executable path for its child processes. However, in a QEMU user-mode environment, this might not work as expected because QEMU emulates the system calls and could be handling the `/proc` filesystem differently.
The user suggests modifying the `exec` syscall to replace `/proc/self/exe` with the real path. They also provided a patch that changes how Chrome determines its executable path by resolving symbolic links using `ReadSymbolicLink`. This seems to address the problem by getting the actual file path instead of relying on the symbolic link.
Looking at the possible categories: instruction, syscall, runtime. The issue here doesn't seem to be about faulty instructions or system calls directly failing. Instead, it's more about how Chrome is handling its process forking in a runtime environment that behaves differently (QEMU user mode). So, this falls under runtime issues because it's an error that occurs during the execution of the application when interacting with a specific environment.
Therefore, I think the category is 'runtime'.
</think>
runtime
|