https://bugs.kde.org/show_bug.cgi?id=511717
--- Comment #13 from Philippe Waroquiers <[email protected]> --- (In reply to Libor Peltan from comment #9) > I tried to prevent simultaneous access by multiple vgdb to the running > Valgrind, now only subseqent (but still multiple) readouts are enabled. > In fact, the vgdb is always invoked like this: gdb -ex "set confirm off" -ex > "target remote | vgdb -d -d -d -T --pid=<valgrind_pid>" -ex "info threads" > -ex "thread apply all bt full" -ex q <knot_dns_binary> > The issue is still reproducible in those conditions. > What I can see is usually: > - in the valgrind output, nothing interesting, just a SIGSEGV reaction > - in the gdb stdout, the print of the bactrace is cut half just after some > thread header: Thread 4 (Thread 210684 (tid 4 VgTs_WaitSys)): > - in the gdb stderr, the message "No registers." appears. Subsequent lines > probably belong to subsequent calls of gdb which fail to attach. > I'm attaching the most verbose output of valgrind, vgdb (stdout) and vgdb > (stderr). Please note that this is appended from multiple (subsequent) runs > of (v)gdb. I took a (very) quick look at the logs. I do not see how the gdbserver code can start processing an m packet (indicated in the stack trace of the SEGV) and have the attached trace. Normally, the trace -d -d -d -v -v -v contains a lot more trace (in particular when gdbserver is invoked). Maybe the option -log-file=/tmp/knottest-1762872011-o00w3twa/ctl/concurrent#4/knot1/valgrind interacts ? In any case,I see that you are using valgrind 3.21 while last release is 3.26. I suggest to upgrade to the last release and redo the experiment (including with the -v -v -v -d -d -d trace) but then see where is the expected traces such as: .... --10179:1: gdbsrv invoke_gdbserver running_tid 0 vgdb_interrupted_tid 1 --10179:1: gdbsrv entering call_gdbserver vgdb_reason ... pid 10179 tid 1 status VgTs_WaitSys sched_jmpbuf_valid 1 --10179:1: gdbsrv enter valgrind_wait pid 10179 --10179:1: gdbsrv adding_thread ti* 0x0 vgtid 1 status VgTs_WaitSys as gdb ptid id 10179 lwpid 10179 --10179:1: gdbsrv adding_thread ti* 0x0 vgtid 2 status VgTs_WaitSys as gdb ptid id 10180 lwpid 10180 --10179:1: gdbsrv adding_thread ti* 0x0 vgtid 3 status VgTs_WaitSys as gdb ptid id 10181 lwpid 10181 --10179:1: gdbsrv adding_thread ti* 0x0 vgtid 4 status VgTs_WaitSys as gdb ptid id 10182 lwpid 10182 --10179:3: gdbsrv fetched register 16 size 8 name rip value 00000000049779dc tid 1 status VgTs_WaitSys --10179:1: gdbsrv stop pc is 0x49779DC --10179:1: gdbsrv exit valgrind_wait status T ptid id 10179 stop_pc 0x49779DC: select (select.c:69) signal 5 --10179:1: gdbsrv Opening write side /tmp/vgdb-pipe-to-vgdb-from-10179-by-philippe-on-md --10179:1: gdbsrv result fd 3 --10179:1: gdbsrv result safe_fd 1031 --10179:3: gdbsrv [getpkt: discarding char ''] --10179:3: gdbsrv getpkt ("QStartNoAckMode"); [sending ack] --10179:3: gdbsrv [sent ack] --10179:3: gdbsrv putpkt ("$OK#9a"); (binary len 6) [no ack] Thanks -- You are receiving this mail because: You are watching all bug changes.
