> > The only other way I can think of to solve this is to send my module list > > to this audience. Please find it, attached, with home-grown modules > > deleted. > > Have you tried debugging the old-fashioned way, i.e. remove things until it > works? That's your best bet. I suspect you will find that you have some > module doing something with XS or sockets or filehandles that can't deal > with being forked.
That's just the thing with memory corruption: Adding or removing random code causes the SIGSEGV signature to change (or causes the server to suddenly start working). I am nearly certain that the memory corruption is happening BEFORE the fork, anyway, which is why I modified the subject line of this thread. Thank you VERY, VERY much for your ideas, though - I will keep looking while I wait for the powers that be to get my bounds checking software! > - Perrin -- \_/} Mark P. Fister Java, Java, everywhere, and all \_/} \_/} eBay, Inc. the cups did shrink; Java, Java \_/} \_/} Austin, TX everywhere, nor any drop to drink! \_/}
