|
|
Boost Testing : |
From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2005-03-16 10:02:59
Aleksey Gurtovoy wrote:
> Carl Daniel writes:
>> A couple of things that will help (I haven't yet tried to find the
>> appropriate sources to see what's in there already). The main() for
>> tests (and maybe bjam itself) should be written something like:
>>
[ code snipped]
>>
>> with that code in place in the test programs' main(), there should
>> be no more dialogs from the CRT/Debugger.
>
> That's MSVC specific, though, right?
Yep :( I don't know how portable it would be to other Windows compilers as
I have none to test. I'd expect Intel C++ would support it verbatim - no
idea about CW or Borland, but I'd bet that there's an equivalent (if they
don't also support it as-is). With the debug monitor discussed below, these
changes wouldn't be needed - but in the absense of such a monitor, these
changes would help immediately.
>> To handle all cases - like missing DLLs, as well as handle stuck
>> programs, the best solution may be to write a custom
>> debugger/lancher that's used as a trampoline for launching all child
>> processes of bjam (or at least the tests, compiler and linker).
>
> This is our current understanding as well.
>
>> so, rather than invoke cl.exe <arguments>, bjam would invoke monitor
>> <timeout> cl.exe <arguments>, or similar.
>
> Ideally, bjam itself should be monitored as well, so I'd say the
> command line for running tests would be
>
> monitor <timeout> bjam ....
That should be fine with a sufficiently high <timeout> for bjam :)
> Obviously, timeout would apply only to the child processes.
In this original version, I was assuming that <timeout> applies only to the
process that's an immediate child of the monitor process. If further child
processes are to be monitored, they need to be launched by additional
instances of the monitor. It would be a simple matter to also terminate all
child processes of the debugee, but since the debugger wouldn't be attached
to them it wouldn't have the ability to detect exceptions (etc) or attempts
to display a GUI in those child processes.
I assume that right now the process hierarchy looks like this:
python.exe
bjam.exe
cl.exe
link.exe
foo_test.exe
bar_test.exe
...
and that there are no cases in which a test process creates child processes.
Is that correct?
>> A debugger/launcher like that is not a difficult program to write.
>> Such a debugger could also hook any number of Windows API functions
>> (CreateDialog, etc) to prevent the subject process from creating any
>> kind of GUI. A debugger can intervene in the DLL loading process as
>> well (I believe - I haven't verified that).
I've confirmed that the missing DLL messages can be handled by a debugger -
the OS raises exception 0xC0000135 when a loader error occurs and the
debugger can handle that exception by simply terminating the debugee.
> Sounds perfect.
>
>> One downside to the debugger solution is that the test runner would
>> be required to have SeDebugPrivilege. I would expect that nearly
>> all (if not all) developers (and their regression test suites) are
>> running with SeDebugPrivilege already, since you cannot debug
>> without it.
>
> Yes, I don't think that's going to be a problem.
>
>>
>> I'm willing to take on writing that debugger/launcher if it sounds
>> like it could help.
>
> It most definitely does!
OK, I'll look into the details.
Another option, easier to use (but harder to write) would be a debugger that
attaches to all child processes that are created as well, so the whole
package would be run something like:
monitor /config=<config file> bjam.exe <arguments>
where the config file would specify behavior for control of child processes
by image name (with wildcards).
That sounds like a monitor V2 solution to me - multi-process debuggers are
considerably more complex to write.
-cd