https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #16 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to Nick Briggs from comment #15) > Also note: drd/tests/pth_mutex_signal when run under simple memcheck, fails > because pthread_mutex_lock() returns EINTR, while POSIX says of it (and > related functions) "These functions shall not return an error code of > [EINTR]." The big question is why Linux and FreeBSD aren't restarting their respective _umtx_op/futex system calls. Both are using internal kernel values of errno that indicate that the sycall should be restarted, ERESTARTNOINTR on Linux and ERESTART on FreeBSD. When running standalone, the signal handler will create a sigframe with the return trampoline doing a sigreturn to the syscall. When running under Valgrind, things are a lot different. We will have replaced the client signal handler by async_signalhandler. So when the signal arrives, this is what gets called, with a sigframe for sigreturn back to the syscall. But we will never return from async_signalhandler. Instead async_signalhandler calls fixup_guest_state_after_syscall_interrupted *** which does not handle kernel restartable syscalls *** async_signalhandler then calls deliver_signal which synthesizes an extended sigframe with out own return trampoline that does a (fake) sigreturn. async_sighandler jumps back to the scheduler, which will then run the guest signal handler. That will return via our trampoline to our (fake) sigreturn. This fixes up the Virtual CPU to make it look like the client is returning to the syscall but then (fake) sigreturn just sets the status (so there is no real syscall) and returns back to the Valgrind scheduler. That all takes us back to where fixup_guest_state_after_syscall_interrupted said to go after the sigreturn. We'd like it to restart the syscall, like when running standalone. But that doesn't seem to be the case at the moment. -- You are receiving this mail because: You are watching all bug changes.
