https://bugs.kde.org/show_bug.cgi?id=458915
--- Comment #3 from Libor Peltan <libor.pel...@nic.cz> --- @Paul Helgrind reports oh so many errors, I can hardly find any clue in them. I guess this tool is not intended for debugging (mostly) lockless multi-threaded programs (where concurrency is controlled by libRCU or other tricks). Anyway, when I run `valgrind --tool=helgrind`, the described bug appears as well with roughly equal frequency as for memcheck. DRD also reports a ton of errors. It's so slow that it doesn't even pass the test scenario in time limit, so I'm not making any conclusions from it. Shall I walk through those tons of errors and look for something specific? I tried applying the patch called "Patch for FreeBSD" from #445743, as well as the hint from its 14th comment. This did not change anything, the bug persists. @Philippe If I hadn't overlooked something, strace does not report any signal received shortly before the crash, besides the SIGABRT resulting from it. Anyway, it seems to me, that the actual futex syscall is not in fact called as well, but I'm not 100% sure. I'm going to attach the valgrind output from the crashing run of the test, with the parameters `-v -v -v -d -d -d --trace-syscalls=yes --trace-signals=yes --trace-sched=yes` as you suggested. It's pretty long, please grep for the word "abort". My speculations around RAX are based on the idea that if, due to some bug, the syscall is not in fact called by valgrind, but expected to have been called, the syscall number in RAX could be easily misinterpreted to be the return value in RAX. But this is of course too simple a view. -- You are receiving this mail because: You are watching all bug changes.
