https://bugs.kde.org/show_bug.cgi?id=511717
--- Comment #8 from Philippe Waroquiers <[email protected]> --- (In reply to Libor Peltan from comment #7) > Great question! > > I found out the what happens is that vgdb is attached to the running > Valgrind process. (This is done by a script whenever something goes wrong > with the application, unrelated to this issue.) > > In fact, the issue appears when multiple instances of vgdb are attaching to > the Valgrind process. Do you think it is possible that the crash appears > when one vgdb instance is trying to connect, while another one is already > reading out the (large) backtrace? Strange: as part of the logic that vgdb uses to connect to the valgrind gdb server, it acquires a lock. If you already have a vgdb connected, the second vgdb should tell something like: syscall failed: Resource temporarily unavailable Cannot acquire lock. Probably vgdb pid 180040 already speaks with Valgrind pid 164492 So, in theory, there is no way to have two vgdb connected and interacting. If the lock has not forbidden the two vgdb to attach simultaneously, that is likely to cause problems (that is the original reason why the lock was needed). It might be worth adding debugging options to vgdb such as -d -d -d -T and see in which order which vgdb do what. That might explain how you can get several vgdb (or gdb) interacting with valgrind Note that your valgrind gdbserver crashes in valgrind_read_memory (used for m or x packets, reading memory). This indicates that there is at least one of the two vgdb that is launched by gdb as I see no way the standalone vgdb would read memory of the valgrind process. -- You are receiving this mail because: You are watching all bug changes.
