https://bugs.kde.org/show_bug.cgi?id=511717
--- Comment #18 from Philippe Waroquiers <[email protected]> --- (In reply to Libor Peltan from comment #17) > Thank you for looking on this. > > I now attached the output of reproducing the issue with current version of > Valgrind (built from git master branch). (Sorry for attaching the output of > an old version beforehand, I was just trying if the issue reproduces with > old Valgrind as well (it did) and forgot to go back to recent.) > > I also stripped the option --log-file, which indeed led to more output lines > as you illustrated. I just needed to capture stderr which was easy. > > Please take a look on the updated attachments :) I took a look but sadly, that has not clarified what happens What is strange is that the valgrind gdbserver first checks (using the valgrind address space manager) that the memory is readable before effectively reading the memory. And the readibility check is just before the memory reading. So, this seems to point at the valgrind address space manager not up to date (or corrupted?). The faulting address is 0x2EB0C000. This is just one page after the last client thread stack allocated: --25778:2: stacks register [start-end] [0x2E30B000-0x2EB0AFFF] as stack 27 And just after this client stack registration, we see: --25778-- di_notify_mmap-1: 0x2e30b000-0x2f30cfff rw- So, the address space manager has been informed that this memory range is rw. The fault happens when thread 4 is busy creating a new thread and is blocked in the madvise syscall used I believe by the pthread library to setup the client stack protection. Possibly we have some race condition between the gdbserver/gdb/valgrind when a thread is just being created. What I suggest is to re-run the test case causing the fault but adding yet more trace on the valgrind side e.g. -v -v -v -d -d -d --trace-syscalls=yes --trace-signals=yes --core-redzone-size=64 --trace-malloc=yes --vgdb-stop-at=valgrindabexit (the redzone arg adds a bigger red zone between the memory allocated by Valgrind in case V code itself has a buffer overrun) valgrindabexit indicates that the gdbserver should be called when valgrind itself encouters a problem. This is however unlikely to work as the problem happens when we are already inside the gdbserver. But possibly this means valgrind will not crash/will block. Then doing cat /proc/<VALGRIND_PID>/maps can be used to see if the faulting address is (or is not) mapped rw (or at least r). -- You are receiving this mail because: You are watching all bug changes.
