Boost logo

Boost Interest :

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-06-28 01:44:53

Beman Dawes wrote:
> On Wed, Jun 18, 2008 at 8:25 AM, troy d. straszheim <troy_at_[hidden]
> <mailto:troy_at_[hidden]>> wrote:
> I've seen this but haven't had time to dig in and solve it yet.
> CPU usage drops to zero and the thing just sits there
> Yes, those are the symptoms I'm seeing here.
> (there is no
> network connection open, that isn't the problem). There is
> something fishy with the python subprocess stuff (on windows.
> darwin/linux are fine.) that I haven't had time to look at.
> Any Python win32api experts out there who could look at this?

I got this worked out, it took quite a number of tries. My vista box
is doing a good job now. I also threw together a little build slave
script, the builds posted on
were done by boxes that are still periodically checking the cmake
release branch for new revisions. More when it is documented.

One thing that still happens is that "Visual C++ Debug Library Assertion
Failure" popups still come up, but the compile/link/test driver program
does time them out and kill them. GPFAULT dialogs don't appear at all.
  There is a failing date_time test (testtime_wstream i believe) that
passes a null string to a function like sprintf() and the popup comes
from the guts of that function. Evan put me on to a way to suppress these:

    _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
    _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );

The test that causes this is just a program with a main() routine...
It seems like it should use boost.test, and boost.test should be
responsible for making these dialog-suppressing calls. (Does that sound
like it makes sense?)


Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at