[Boost-testing] Re: build_monitor - making it work better

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-03-16 22:32:01

Carl Daniel writes:
> 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.

AFAIK all Win32 regregression runners currently employ '--monitored'
option, so in the short run, we are already covered. I think it'd be
more beneficial for us to concentrate on fixing the monitor's
shortcomings instead of spending resources on partial solutions.

>
>>> 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.

Unfortunately, this won't always work. At least Comeau and GCC launch
their own child processes to the the actual compilation/linking.

> 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.

Hmm, here's the first complication, then.

>
> 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?

AFAIK, _tests themselves_ do not launch any child processes, but
compilers can and do. IOW, the hierarchy looks more like

  python.exe
      bjam.exe
          cl.exe
          como.exe
             somethingrather.exe
             linksomethingrather.exe
          g++.exe
             somethingrather2.exe
          link.exe
          foo_test.exe
          bar_test.exe
          ...

>
>>> 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.

Wonderful!

[...]

>>> 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.

Thank you. Your help on this is very much appreciated.

>
> 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.

I definitely agree that we should go for the simpliest thing that
covers all use cases.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering