Boost logo

Boost Testing :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-02-05 01:50:20

Rene Rivera wrote:
> David Abrahams wrote:
>> Well, I'm afraid we really need that "way around" if we're going to
>> have effective automated testing on Windows. Otherwise a crashed test
>> stalls the whole process; a new test run won't start until all those
>> dialogs are closed.
> I don't believe that's true, at least on Win2K. The debug/assert popups
> are put up by a a debugger process, not the process that crashes, and
> hence not a process that is reachable through the usual parent/child
> process hierarchy. That means that when the dialogs come up, bjam is
> still running, it's just the crashed program that isn't. At some point
> the action timeout on bjam will kick in and kill any children of that
> action and proceed with the next test. So it only looks like the testing
> is stalled. What Bronek's code does, is attempt to close those popups
> before the timeout happens, to avoid having to wait for the action
> timeout. But as he says, it's not perfect.
> The perfect solution is to make bjam, or some other monitor program,
> into a real debugger process. Which would then be able to catch those
> assertions, and perhaps even print out stack traces and process info.

Just my observations:

I am running with bjam option -l600
which lets the pop ups hang around, but the regression finishes.

At the very end when I close the containing cmd, shell (from where was launched) all the pop ups go away too.


Boost-testing list run by mbergal at