1 files changed, 31 insertions, 0 deletions

diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/654.toml b/gitlab/issues/target_missing/host_missing/accel_missing/654.toml
new file mode 100644
index 000000000..f009f2b96
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_missing/654.toml
@@ -0,0 +1,31 @@
+id = 654
+title = "Strace Log Output Mangled"
+state = "opened"
+created_at = "2021-09-30T20:56:51.392Z"
+closed_at = "n/a"
+labels = ["linux-user"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/654"
+host-os = "Ubuntu 20.04"
+host-arch = "x86_64"
+qemu-version = "qemu-x86_64 version 6.1.50"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is
+complete.
+This makes parsing the strace syscall lines from the log output difficult."""
+reproduce = """1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps
+2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output"""
+additional = """I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace)
+
+
+I believe this bug caused by a couple of things:
+Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls:
+The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153
+And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160
+
+In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output:
+https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633
+There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior.
+
+
+Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above."""