Some questions to ask: 1. Is it more stable in a 32-bit environment? 2. Does a 'lite' version (no actual work, but threads are scheduled and run) of your MT framework throw out the same problem? 3. Have you thrown in eval() at critical points to capture exceptions? Bear in mind eval in threads works slightly different.
[EMAIL PROTECTED] wrote: > Here's a difficult 'perl' debugging problem. > > Have a relatively simple but multi-threaded script that runs a > bunch of remote 'tasklist' commands via pipe opens every five > minutes, collects the outputs, checks that certain programs and > services are running, and generates e-mail alarms when things > are amiss. > > This script runs fine, but after the first two weeks of > operation it hung. Running under 64-bit Perl 5.10.0 freshly > compiled from the base distribution with Visual Studio 2005 SP1 > C/C++. > > I believe the script is fine and that a problem may exist in > 'perl'. Locks are used to protect a few shared arrays and > semaphores are used to wake up threads. An earlier > multi-threaded issue was resolved by moving from 5.8.8 to 5.10.0 > and it seems the perl MT support is still fairly new and > may have issues. Also googled up a bug from last year > where a condition variables hangs up, though it's not > clear if the fix is in 5.10.0. > > What makes the most sense is to somehow obtain a snapshot of the > state of the interpreters after the next hang, however many > weeks or months out that happens to be. Just knowing where it > gets stuck would get me 85% there. However I don't see any easy > way to dump or attach the perl interpreter process and find out > what's going on unless I want to hack it at the C language level > (i.e. not easy). Tried running with -d but can't seem to > interrupt the script with CTRL-C or CTRL-BREAK. > > For now I'm running both the MT version of this script and an > earlier ST version as a backup. The ST version will hang if any > of the 'tasklist' children hang, but that doesn't seem to happen > even when the network goes to pieces so the ST version will > probably run well enough. If it doesn't hang it will be far > more useful than the MT version even though it's less > technically correct and gathers outputs in a round-robin > line-at-a-time manner from the array of 'tasklist' pipes. For > now the application being monitored is more reliable that the MT > monitoring script. > > _______________________________________________ > Perl-Win32-Users mailing list > Perl-Win32-Users@listserv.ActiveState.com > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
