*sigh*
Turns out this was not the intermittent error I thought it was. I talked with the user some more, and it turns out they had customized the CGI and the library file so it doesn't contain this second subroutine.
BUT, they forgot to update all the URLs in their system. When they called their customized CGI that only used the first subroutine, all was well. When the user clicked on one of the old URLs pointing to the original code (that called both subroutines), it was crashing because the second subroutine isn't defined in the module anymore... (Don't know why.)
Thanks for all the feed-back on this, sorry it was a red herring.
Glad to know it wasn't an instability in the Perl libraries!
Dan
On Sun, Oct 31, 2010 at 08:00, Jay Hannah
<jhannah@mutationgrid.com> wrote:
On Oct 30, 2010, at 3:29 PM, Dan Linder wrote:
> It's a vanilla CGI on a Solaris 10 (Sparc) box.
Huh. Ya, with vanilla CGI (all Perl re-interpretted from scratch on every single web hit) I don't know how that error is possible if the source code isn't changing. :(
> If we're still stumped, I'm hoping to enlist a co-worker who has experience with Dtrace so we may go that route. I'm hoping we can log memory, swap, or process related errors.
If it's only happening every few weeks graphing out your long term system trends (memory, process count, etc.) might show a correlation? http://www.cacti.net/
Make sure to tell us what you figure out. :)
HTH,
--
***************** ************* *********** ******* ***** *** **
"Quis custodiet ipsos custodes?"
(Who can watch the watchmen?)
-- from the Satires of Juvenal
"I do not fear computers, I fear the lack of them."
-- Isaac Asimov (Author)
** *** ***** ******* *********** ************* *****************
_______________________________________________
Omaha-pm mailing list
Omaha-pm@pm.org
http://mail.pm.org/mailman/listinfo/omaha-pm