https://bugs.kde.org/show_bug.cgi?id=458915
--- Comment #17 from Libor Peltan <libor.pel...@nic.cz> --- Thank you much for looking at this issue constantly! I confirm that with --tool=none, the issue reproduces as well. This is also true for --tool=helgrind, as I said earlier. Even with --vex-iropt-register-updates=allregs-at-each-insn , the issue still reproduces with the same frequency. I took much closer look at the signals in our application. SIGALRM can be sometimes sent by the program to itself in order to notify all the threads about something. However, the issue reproduces even in cases when neither SIGALRM nor any other signal arrives around the time the issue happens. So it must be caused (also) by something else. I'm going to attach the logs from two more different test-cases. In one case, both epoll and futex return the invalid values (0xe8 and 0xca, respectively), which results in that assert in glibc and following SIGABRT, which is however the consequence, not the cause of the issue. In the second case, only epoll returns wrong 0xe8 value and the program continues running to the end, when only at the very end SIGTERM is received. The valgrind params were "--tool=none -v -v -v -d -d -d --vex-iropt-register-updates=allregs-at-each-insn --trace-syscalls=yes --trace-signals=yes --trace-sched=yes --num-callers=20 --trace-children=yes --trace-children-skip=/usr/*sh,/bin/*sh" in both cases. It seems to me that different threads seem to suffer the same in one moment. Sometimes the issue happens only once for one thread, sometimes multiple threads receive the wrong syscall retcodes in close succession. But mostly without any signal observed, if I'm not overloking something terribly. Finally, I confirm that even with --vex-iropt-register-updates=allregs-at-mem-access , the issue still reproduces. -- You are receiving this mail because: You are watching all bug changes.
