|
From: Jeremy F. <je...@go...> - 2005-02-23 07:17:36
|
CVS commit by fitzhardinge:
Report lost siginfos a bit more idiomatically.
M +24 -8 vg_signals.c 1.130
--- valgrind/coregrind/vg_signals.c #1.129:1.130
@@ -1728,12 +1728,4 @@ void vg_sync_signalhandler ( Int sigNo,
Bool resume_sched = False;
- if (info->_sifields._kill._pid == 0) {
- VG_(message)(Vg_UserMsg, "Signal %d (%s) appears to have lost its siginfo; I can't go on.",
- sigNo, signame(sigNo));
- VG_(message)(Vg_UserMsg, " This may be because one of your programs has consumed your");
- VG_(message)(Vg_UserMsg, " ration of siginfo structures.");
- exit(99);
- }
-
if (VG_(threads)[tid].status == VgTs_WaitSys) {
/* This is like a normal async signal, but we can't simply
@@ -1749,4 +1741,28 @@ void vg_sync_signalhandler ( Int sigNo,
}
+ if (info->_sifields._kill._pid == 0) {
+ /* There's a per-user limit of pending siginfo signals. If
+ you exceed this, by having more than that number of
+ pending signals with siginfo, then new signals are
+ delivered without siginfo. This condition can be caused
+ by any unrelated program you're running at the same time
+ as Valgrind, if it has a large number of pending siginfo
+ signals which it isn't taking delivery of.
+
+ Since we depend on siginfo to work out why we were sent a
+ signal and what we should do about it, we really can't
+ continue unless we get it. */
+ VG_(message)(Vg_UserMsg, "Signal %d (%s) appears to have lost its siginfo; I can't go on.",
+ sigNo, signame(sigNo));
+ VG_(message)(Vg_UserMsg, " This may be because one of your programs has consumed your");
+ VG_(message)(Vg_UserMsg, " ration of siginfo structures.");
+
+ /* It's a fatal signal, so we force the default handler. */
+ VG_(set_default_handler)(sigNo);
+ VG_(deliver_signal)(tid, info);
+ VG_(resume_scheduler)(tid);
+ exit(99); /* If we can't resume, then just exit */
+ }
+
if (VG_(clo_trace_signals))
VG_(message)(Vg_DebugMsg, "Routing user-sent sync signal %d via queue; resume_sched=%d",
|