5 Commits

Author SHA1 Message Date
Philippe Waroquiers
d4afe02753 Increase some sleep time to (try to) avoid some failure.
With the new sleep time, no failure on 1200 runs of the test.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13916
2014-04-27 08:23:17 +00:00
Philippe Waroquiers
38471445e1 Make the test (more) deterministic by having send_signal using
a guardcmd before sending the signal.
This allows to be sure that the signal are emitted when vgdb
is attached.
We still have one 'sleep' in the test.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13912
2014-04-26 20:23:47 +00:00
Philippe Waroquiers
5bdc88da20 Improve the comments in the test
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13911
2014-04-26 20:01:28 +00:00
Philippe Waroquiers
922a8c4f8d Due to timing problem, test was not properly testing.
What needs to be ensured is:
   vgdb is attached (i.e. is ptracing valgrind)
   2 sigusr1 signals are sent while vgdb is ptracing
     vgdb will queue these signals
   when continuing, the queued signals are delivered.

With 3.9.0, the above causes an internal error in valgrind:
valgrind: m_syswrap/syswrap-main.c:1436 (vgPlain_client_syscall): Assertion 'sci->status.what == SsIdle' failed.

It would be better to have explicit synchronisation in the test
rather than counting on 'sleep xxx' to have things done in the
order that tests the signal queueing.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13910
2014-04-26 19:55:33 +00:00
Philippe Waroquiers
74fb3e1c3e vgdb must not transmit signals when gdbserver has been ptrace-invoked.
Most of the time, Valgrind masks async signals, and polls for such
signals at regular interval.
There is a very narrow range of code (around client syscall logic)
where such signals are unmasked (as they must be able to interrupt
syscalls).
This is the only range of code where Valgrind is expecting to
receive such a signal.

When gdbserver is ptraced invoked, Valgrind is artificially made
to jump out of this code portion. Signals are not masked.
When ptraceing valgrind, vgdb will get these signals but cannot
transmit them immediately, otherwise they arrive in range
of code where they are not expected (causing internal error
in syscall logic) and/or causing gdbserver syscalls to be
interrupted.

3 solutions to solve that were looked at:
1. have the gdbserver code masking signals "as quickly as possible".
 Easy to implement, but this leaves still a small window
 of code where signals are not masked and would cause a problem.
2. have vgdb setting the SIGMASK of valgrind before invoking
  gdbserver.
  This would be easy to implement, but changing the SIGMASK
  of the ptrace-d process is only available on very recent kernels.
3. have vgdb queuing signals, and only transmitting them once
   gdbserver invocation is finished.
This 3rd solution has been implemented.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13896
2014-04-15 22:35:23 +00:00