From: Bob R. <bo...@br...> - 2004-11-29 19:20:13
|
On Mon, Nov 29, 2004 at 04:34:37PM +0000, Tom Hughes wrote: > In message <20041129172039.GA1953@white> > Bob Rossi <bo...@br...> wrote: > > > On Tue, Nov 02, 2004 at 06:33:13PM +0000, Tom Hughes wrote: > > > >> That means you must have a thread with more than eight outstanding > >> signals which seems a bit strange. > >> > >> Note that this is signals which are in the process of being delivered > >> so this is after signal block masks have been considered. > >> > >> You should raise a bug for it anyway. > > > > Sorry for the long delay in the reply. > > > > - Is there an easy way to change the limit to more than eight? > > There is a VG_N_SIGNALQUEUE define in one of the files that controls > the number of slots in the queue. > > I'm not at all sure that increasing will help however as I think you > may have a more fundamental problem. To be honest I had thought that > eight slots was probably overkill. I changed the limit to 16 and for some reason this allows my program to run fine. Is it possible that I need this adjustment and valgrind should be modified? or is it more likely that something is wrong with my configuration? I would be happy to send in the patch, however, I think that maybe someone else would be able to apply a minor change like this ... > > - Would I be able to fix this myself? > > It rather depends on what the problem is and what your experience with > valgrind and kernel signal handling is, not to mention what the actual > problem is... > > I'd start by getting some --trace-signal=yes output and seeing what > signals it is showing. OK, I sent the output with this option set, although it is waiting to be moderated. Maybe you will see something interesting. Thanks, Bob Rossi |