Dear list, Our manager has found the culprit. Someone has set some weird memory config settings in the /etc/system. Kicking them out and rebooting our server has solved the problem. I wish to thanks Darren for his help. Em Seg, 2004-09-20 `s 15:30, Darren Dunham escreveu: > > Thanks for the suggestion.=20 > > > > I ran it and, for my surprise, it creeped with the attached output. > > Could you help me with the analysis? > > All I'd do is look for a segfault in the output and see which process it > belonged to. > > If it didn't segfault, I'd wonder if you were running it the same > way... Do either of these segfault on your machine? > > % cat script.csh > set LALA =3D "`ps -ef | grep XPTO | grep -v grep`" > echo $LALA > % csh script.csh > % truss -f -o /tmp/out csh script.csh > > > > ... (zilllions of the last two lines) > > > > 165: close(16377) Err#9 EBADF > > Unfortunately, you've trimmed the first lines of 165. That would > determine which process it was. > > > 185: brk(0x0006C000) = 0 > > 185: execve("/bin/ps", 0x00062134, 0xEFFFF9C8) > > 185: *** cannot trace across exec() of /bin/ps *** > > Hmm. That's annoying. I wonder why. I don't seem to have similar > problems on a Solaris 8 machine. Are you running this as root or > non-root? > > Try it as root if you can. > > > 165: Incurred fault #6, FLTBOUNDS %pc = 0x000283E8 > > 165: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000008 > > 165: Received signal #11, SIGSEGV [default] > > 165: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000008 > > 165: *** process killed *** > > And we see here that 165 is the one that segfaults. > > I'm wondering if 165 has an exec line near it's beginning that points to > a particular executable being run. -- Feng Sian +55 (11) 2123 2382 feng.sian@interchange.com.br _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Mon Sep 20 14:59:04 2004
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:38 EST