At 03:03 PM 3/19/2008 +0800, you wrote: >Some questions to ask: . . . Don't have endless time for this--otherwise it would be written in C++ and, ironically, a simple debug attach would tell what's going on when it hangs. Probably the single-thread version will run forever, so can't justify spending a lot of time on the MT version.
I'm looking for a way to get directly at what the state of the perl threads are when it fails approximately every 300 hours or so. In C++/C udner Linux you can do that with an -g -O3 build and gdb attach or use 'kill -ABRT' to take a core dump and analyze that. If one doesn't read assembler, then skip the -O3 and hope the bug is not dependent on optimization. Thirty minutes after the event what happened is known with precision. Under Windows one can use 'windbg' to capture a dump and combine that with the .PDB file for a post-mortim. Or just attach the live process from the Visual Studio IDE. I'm having trouble believing that one can't get a snapshot of the state of a perl execution environment to analyze, online or offline. However this seems to be the situation as far as I can tell. I can wait for 18 months for the next version of 'perl' to see if it fixes it. Was just hoping for a better way that doesn't involve an incredible expenditure of effort on a minor script. _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
