https://bugs.kde.org/show_bug.cgi?id=458915
--- Comment #8 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
I took a look at both logs.
First the epoll log.
(tid is the an thread id number used internally in valgrind)
What we see is that the tid 14 is just getting the result of a previous epoll
syscall, and then starts a new epoll syscall:
....
--111235-- SCHED[14]: acquired lock (VG_(client_syscall)[async]) <<<<<
tid 14 acquires the valgrind lock as the epoll syscall ended
SYSCALL[111235,14](232) ... [async] --> Success(0x0)
<<<<< and the tid 14 reports the success of this syscall
--111235-- SCHED[14]: TRC: SYSCALL
<<<<< it launches a new epoll syscall
SYSCALL[111235,14](232) sys_epoll_wait ( 18, 0x2610f740, 1, 1000 ) --> [async]
...
--111235-- SCHED[14]: releasing lock (VG_(client_syscall)[async]) ->
VgTs_WaitSys <<<<< and releases the lock waiting for the result
--111235-- SCHED[35]: acquired lock (VG_(scheduler):timeslice)
<<<<< and the tid 35 acquires the lock
.....
Then later on, the tid 18 calls tgkill sending a (fatal) signal to itself (I
believe it is to itself, the tracing of valgrind of the link
between the tid and the linux thread id is not very clear).
As this signal is fatal, all threads are being killed by valgrind
We see that a little bit before the tgkill that tid18 does a write on fd 2.
Possibly that is an indication of reporting an error/problem.
The problem with the futex has a similar pattern:
The tid 6 starts a futex syscall and releases the valgrind lock.
Then sometime later, the tid 11 is doing an mmap, and then slightly after
calls tgkill.
And similarly this tid 11 does a write on fd 2 a little bit before.
The processing of a fatal signal in valgrind is quite tricky : complex code,
with race conditions see e.g. bug 409367.
This fatal signal has to get all the threads out of their syscalls.
For this, a kind of internal signal "vgkill" is sent by the valgrind scheduler
to all threads.
When the signal is received, valgrind detects that the thread was in a syscall
and that the thread
has to "interrupt" the syscall. For this, valgrind calls VG_(post_syscall). But
this post_syscall assumes that the guest state
is correctly "fixed", but I do not see where this is done.
So, an hypothesis about what happens:
* the application encounters an error condition (in tid 18 in the epoll case,
in tid 11 in the futex case)
* this application thread decides to call abort, generating a fatal signal
* valgrind handling of a fatal signal is for sure complex and might still be
racy, and might not properly reset the guest state
when the fatal signal has to be handled by a thread doing e.g. epoll or
futex syscall
As the guest state is not properly restored, when this thread "resumes" and/or
due to race conditions, instead of just dying, it continues
and then itself reports a strange state as the guest thread state was not
properly restored using a call to
VG_(fixup_guest_state_after_syscall_interrupted).
To validate this hypothesis, maybe the following could be done:
* check what is this "write on fd 2" doing (maybe with strace?)
* in case the application encounters a problem, instead of calling abort that
sends a fatal signal, you might rather do e.g. sleep(100000).
If the hypothesis is correct, then the thread doing epoll or futex should
just stay blocked in their syscall,
and the thread detecting the problem will sleep in this state.
It might then be possible to attach using gdb+vgdb and investigate the state
of the application and/or the valgrind threads.
There is a way to tell valgrind to launch gdbserver in case of an abnormal
valgrind exit using the option:
--vgdb-stop-at=event1,event2,... invoke gdbserver for given events [none]
where event is one of:
startup exit valgrindabexit all none
Looks like we might add abexit to ask valgrind to call gdbserver when a client
thread/process does an abnormal exit.
--
You are receiving this mail because:
You are watching all bug changes.
