https://bugs.kde.org/show_bug.cgi?id=458915
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #2 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
Does strace show that there are some signals being processed close (in time) to
the system call wrongly returning its syscall number ?
If a signal happens when syscall-amd64-linux.S is being executed,
then VG_(fixup_guest_state_after_syscall_interrupted) has some complex logic
that interacts with the partially executed asm code.
Alternatively, having more valgrind tracing might give some hints.
You could try
valgrind -v -v -v -d -d -d --trace-syscalls=yes --trace-signals=yes
your_app
and if your application is multi-threaded (I guess it is), you might also use
--trace-sched=yes
With regards to "What intrigues me that both the syscall number and the return
value appear in the RAX register at some point."
If you speak about the "physical RAX register", then I think this is normal. To
execute a syscall, the syscall number must be set
to the syscall number before the syscall instruction, and on return of the
syscall instruction, the RAX register contains the syscall return value.
When this syscall instruction is finished, the syscall return code (stored by
the kernel in the physical register RAX)
must be moved to the guest register RAX.
--
You are receiving this mail because:
You are watching all bug changes.
