|
From: <sv...@va...> - 2005-08-16 01:39:41
|
Author: njn Date: 2005-08-16 02:39:34 +0100 (Tue, 16 Aug 2005) New Revision: 4425 Log: Give more info about seginfo dropping. Modified: trunk/coregrind/m_signals.c Modified: trunk/coregrind/m_signals.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/coregrind/m_signals.c 2005-08-15 13:29:43 UTC (rev 4424) +++ trunk/coregrind/m_signals.c 2005-08-16 01:39:34 UTC (rev 4425) @@ -1831,6 +1831,16 @@ sigNo, signame(sigNo)); VG_(message)(Vg_UserMsg, " This may be because one of your programs h= as consumed your"); VG_(message)(Vg_UserMsg, " ration of siginfo structures."); + VG_(printf)( +" For more information, see:\n" +" http://kerneltrap.org/mailarchive/1/message/25599/thread\n" +" Basically, some program on your system is building up a large queue o= f\n" +" pending signals, and this causes the siginfo data for other signals t= o\n" +" be dropped because it's exceeding a system limit. However, Valgrind\= n" +" absolutely needs siginfo for SIGSEGV. A workaround is to track down = the\n" +" offending program and avoid running it while using Valgrind, but ther= e\n" +" is no easy way to do this. Apparently the problem was fixed in kerne= l\n" +" 2.6.12.\n"); =20 /* It's a fatal signal, so we force the default handler. */ VG_(set_default_handler)(sigNo); |