https://bugs.kde.org/show_bug.cgi?id=458915
--- Comment #9 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to Philippe Waroquiers from comment #8) > So, an hypothesis about what happens: > * the application encounters an error condition (in tid 18 in the epoll > case, in tid 11 in the futex case) > * this application thread decides to call abort, generating a fatal signal > * valgrind handling of a fatal signal is for sure complex and might still > be racy, and might not properly reset the guest state > when the fatal signal has to be handled by a thread doing e.g. epoll or > futex syscall > As the guest state is not properly restored, when this thread "resumes" > and/or due to race conditions, instead of just dying, it continues > and then itself reports a strange state as the guest thread state was not > properly restored using a call to > VG_(fixup_guest_state_after_syscall_interrupted). I was thinking on similar lines of https://bugs.kde.org/show_bug.cgi?id=445743 where the syscall is supposed to never return when interrupted. Under Valgrind it does get interrupted and Valgrind doesn't resume it. It would be interesting to see if strace shows any ERESTARTNOINTR return status values. -- You are receiving this mail because: You are watching all bug changes.
