https://bugs.kde.org/show_bug.cgi?id=458915
--- Comment #19 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
I took a look at the attached logs.
A first observation:
* We have 2 groups of 3 threads that get the 0xe8 syscall return.
* For each of these 2 groups, we see a little bit before these 0xe8 return that
there is a connection to
the embedded gdbserver of Valgrind.
Here are the line number and occurrences of the 0xe8 syscall return:
6 matches for "0xe8" in buffer: valgrind
26734:SYSCALL[61639,20](232) ... [async] --> Success(0xe8)
26774:SYSCALL[61639,17](232) ... [async] --> Success(0xe8)
26789:SYSCALL[61639,15](232) ... [async] --> Success(0xe8)
31141:SYSCALL[61639,14](232) ... [async] --> Success(0xe8)
31176:SYSCALL[61639,16](232) ... [async] --> Success(0xe8)
31206:SYSCALL[61639,13](232) ... [async] --> Success(0xe8)
And here are the 3 matches for the gdbserver:
3 matches for "TO DEBUG" in buffer: valgrind
286:==61639== TO DEBUG THIS PROCESS USING GDB: start GDB like this
26668:==61639== TO DEBUG THIS PROCESS USING GDB: start GDB like this
31121:==61639== TO DEBUG THIS PROCESS USING GDB: start GDB like this
where the first one is the message produced at startup.
Maybe this is a modified executable that triggers a call to vgdb/gdb when it
encounters this syscall problem ?
Or is there something that attaches to the valgrind gdbserver or sends a
command to it ?
Because in this last case, we could possibly have an interaction between vgdb
and many threads blocked in syscalls.
We see in the stderr trace the following:
--61639:2: gdbsrv stored register 0 size 8 name rax value 0000000000000007
tid 1 status VgTs_WaitSys
--61639:2: gdbsrv stored register 0 size 8 name rax value 00000000000000e8
tid 15 status VgTs_WaitSys
--61639:2: gdbsrv stored register 0 size 8 name rax value 00000000000000e8
tid 17 status VgTs_WaitSys
--61639:2: gdbsrv stored register 0 size 8 name rax value 00000000000000e8
tid 20 status VgTs_WaitSys
....
--61639:1: gdbsrv stop_pc 0x4CAC04E changed to be resume_pc 0x4C9CD7F: poll
(poll.c:29)
--61639:2: gdbsrv stored register 0 size 8 name rax value 0000000000000007
tid 1 status VgTs_WaitSys
--61639:2: gdbsrv stored register 0 size 8 name rax value 00000000000000e8
tid 13 status VgTs_WaitSys
--61639:2: gdbsrv stored register 0 size 8 name rax value 00000000000000e8
tid 14 status VgTs_WaitSys
--61639:2: gdbsrv stored register 0 size 8 name rax value 00000000000000e8
tid 16 status VgTs_WaitSys
--61639:1: gdbsrv VG core calling VG_(gdbserver_report_signal) vki_nr 15
SIGTERM gdb_nr 15 SIGTERM tid 1
-
So, for the 2 groups of 3 threads that got 0xe8 syscall return, we see that the
valgrind gdbserver was instructed to put 0xe8
in the rax register.
It is however difficult to relate the stderr output with the valgrind output.
If you could redo the trace with the none tool, but keep together the stderr
and the valgrind output
(i.e. let valgrind do its output to stderr together with its debug log) + add
--time-stamp=yes
that might help to see what happens in which order.
I have to say that at this state, I have not much idea what other things to
look at.
To further investigate and possibly find the bug, likely we will need an (easy
to run) reproducer.
--
You are receiving this mail because:
You are watching all bug changes.
