|
|
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 http://boost.resophonic.com/trac/traash
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?)
-t