Re: handling test hangs/crashes/freezes

One approach would be to try to make the test files themselves more robust (or more fragile) using alarm and potentially spawning a second Perl process to be watched.

Personally, I would let things crash, as most smoke testers have such watchdogs already and will abort a test suite after 5 minutes or so. If a user wants to install a module that crashes the interpreter, they will have to skip tests.

Comment on Re: handling test hangs/crashes/freezes

Replies are listed 'Best First'.
Re^2: handling test hangs/crashes/freezes by bulk88 (Priest) on Apr 30, 2012 at 15:12 UTC
Alarm wouldnt work for me. This is Windows. Alarm on Windows cant break syscalls. The reasons for hanging are I/O and OS threading related. Well, they were until I fixed the reasons for the hangs, but my problem is, if it does "fail" it will fail by hanging. So best idea is not plan for hangs and crashes in tests, since a user shouldnt "normally" see the test fail, and in the rare case it does hang, the user has an automatic watchdog or Ctrl-C/Task Manager to kill it?	[reply]
Re^3: handling test hangs/crashes/freezes by Corion (Patriarch) on Apr 30, 2012 at 15:18 UTC
Yes. On Windows, `alarm` won't help you much, but all the automated testers should have provisions against hanging test suites.	[reply] [d/l]
Re^3: handling test hangs/crashes/freezes by BrowserUk (Patriarch) on Apr 30, 2012 at 15:23 UTC
kill will terminate processes on Windows. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]