Hi Andrew,
> Yesterday, preparatory to issuing a deadline on for a release freeze
I
> thought I'd check out the Windows and Solaris ports and see what
their
> state was.
>
> I got as far as the windows port, which didn't even build. That was
> actually my fault for making some Unix changes. Fortunately Steve
made
> fixes for my carelessness a little while later.
Yes, that should be resolved.
> However, the current windows code doesn't seem to run correctly:
>
> Does anyone have recent experience (I guess pre my breaking
> changes that
> the windows port is functional?).
>
> Because I'd say that this would be a blocker - I just want to be
sure
> that there's not something funny about my environment.
>
> If I run the broker and then run perftest against it perftest
appears
> hang waiting for the connection to start
There is an intermittent (for some it's always, for some it's never)
hang similar to what you describe. I've not been able to reproduce it.
Can you run anything else? Python_tests, maybe?
> I get errors from unit_test - culminating in an abort:
> [Apologies forthe rubbish line breaks]
> Running 234 test cases...
> ****../../../qpid/cpp/src/tests/logging.cpp(175): error in
> "testLoggerFormat": check regexPredicate(
> string("..\\..\\..\\qpid\\cpp
> \src\\tests\\logging.cpp")+":\\d+: foo\n", out->last() ) failed for
> ( ..\..\..\qpid\cpp\src\tests\logging.cpp:\d+: foo,
..\..\..\qpid\cpp
> \src\tests\logging.cpp:174: foo )
> **../../../qpid/cpp/src/tests/logging.cpp(378): error in
> "testQuoteNonPrintable": check expect == line failed [critical null
> \x00tab space newline
> \x80\x99\xFF\x00
> != critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> critical ..\..\..\qpid\cpp\src\tests\logging.cpp:345: foo
> critical null\x00tab space newline
> \x80\x99\xFF\x00
> ]
> *../../../qpid/cpp/src/tests/Uuid.cpp(58): error in
"testUuidIstream":
> check uui
> d == sample failed
> *../../../qpid/cpp/src/tests/Uuid.cpp(66): error in
"testUuidOstream":
> check out
> .str() == sampleStr failed [ba284e1b-a12f-d211-883f-b9a761bde3fb !=
> 1b4e28ba-2fa
> 1-11d2-883f-b9a761bde3fb]
> ******unknown location(0): fatal error in "testOpenFailure": memory
> access viola
> tion occurred at address 0xdddddddd, while attempting to read
> inaccessible data
This is "normal" - I tracked it once to a different behavior between
Microsoft and gcc STL iterators or something similar.
> ..\..\..\qpid\cpp\src\tests\ClientSessionTest.cpp(252): last
> checkpoint
> *************
> *** 5 failures detected in test suite "Master Test Suite"
> Detected memory leaks!
> ... and a long list of leaked blocks...
Yes, once it crashes there are leaks galore. They will be looked at
when unit_test doesn't crash.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
