Roland Schwarz wrote:

Markus Schöpflin wrote:

...

As I don't have any time to really look into these issues (and as there is nothing which stops a ever-running test from hanging the regression test run), I decided to just disable the tests for now.

Would it be of help, if I try to look into these? Could you possibly give me login access to the machine?

I do not have other access to a similar machine at the moment.

This, unfortunately, is not possible. I have access to the former HP TestDrive, but AFAICT I'm the only one outside of HP which still has access to it. But I could try to figure out whether the tests also fail here at COMSOFT with gcc 4.1.0. If yes, it would be easier to provide you with call stacks and such things. Markus

Roland Schwarz wrote:

Markus Schöpflin wrote:

...

But I could try to figure out whether the tests also fail here at COMSOFT with gcc 4.1.0. If yes, it would be easier to provide you with call stacks and such things.

Ok, so we can give it a try.

Here are the first results from our single processor machine here at COMSOFT. 1. GCC 4.0.3, works but note the infos.

time ../../../bin.v2/libs/thread/test/test_thread.test/gcc-4_0_3_tru64/debug/threading-multi/test_thread --log_level=all Running 3 test cases... Entering test suite "Master Test Suite" Entering test suite "Boost.Threads: thread test suite" Entering test case "test_sleep" test_thread.cpp(39): info: check in_range(xt, 2) passed Leaving test case "test_sleep" Entering test case "test_creation" test_thread.cpp(47): info: check test_value == 999 passed ../../../libs/thread/test/util.inl(136): info: check 'Timed test didn't complete in time, possible deadlock.' passed Leaving test case "test_creation"; testing time: 16666mks Entering test case "test_comparison" test_thread.cpp(27): info: check thrd != *parent passed test_thread.cpp(29): info: check thrd == thrd2 passed ../../../libs/thread/test/util.inl(136): info: check 'Timed test didn't complete in time, possible deadlock.' passed Leaving test case "test_comparison" Leaving test suite "Boost.Threads: thread test suite" Leaving test suite "Master Test Suite"

*** No errors detected real 0m6.954s user 0m0.652s sys 0m0.024s 2. GCC 4.1.0, hangs. schoepf@area51:/vol2/boost/src/boost-RC_1_34_0/libs/thread/test> time ../../../bin.v2/libs/thread/test/test_thread.test/gcc-4_1_0_tru64/debug/threading-multi/test_thread --log_level=all Running 3 test cases... Entering test suite "Master Test Suite" Entering test suite "Boost.Threads: thread test suite" Entering test case "test_sleep" test_thread.cpp(39): info: check in_range(xt, 2) passed Leaving test case "test_sleep" Entering test case "test_creation" <CTRL-C> real 0m53.983s user 0m37.044s sys 0m0.041s Anything else I can do? Markus

Roland Schwarz wrote:

Markus Schöpflin wrote:

...

../../../libs/thread/test/util.inl(136): info: check 'Timed test didn't complete in time, possible deadlock.' passed

This is interesting.

Did you use the latest RC_1_34_0? I was am suspecting something around the xtime.cpp implementation already, and put some assertions around the operating system calls to gettimeofday and clock_gettime.

If in doubt please cvs update and do again.

I used that latest RC_1_34_0 from this morning. I just did an update and didn't get any relevant modifications. Markus

Roland Schwarz wrote:

Markus Schöpflin wrote:

...

I used that latest RC_1_34_0 from this morning. I just did an update and didn't get any relevant modifications.

This was the wrong track anyways. I misinterpreted the log info. This info (due to negative logic wording) indeed showed that it passed well.

It seems that even the simplest threading functions are not beeing available. Just an idea: could it be, that the linker tries to link in a bogus library? i.e. an incompatible one. At least the link step relies on the linker finding the correct one.

What do you mean by not being available? You mean there is no threading support in this particular compiler version? Or that the threading functions are somehow broken? AFAIK, it's always the posix thread lib of the underlying OS which is linked.

The regex static_mutex test is failing with a similar result (I suspect you also had to manually stop it?)

Yes, every test but the last two had to be killed manually. Do you have any tests which allow to enable more tracing that would enable us to see where the tests are actually hanging? As they are consuming 100% CPU when hung, I think that this might lead us somewhere. Markus

Roland Schwarz said: (by the date of Mon, 02 Oct 2006 17:38:39 +0200)

Also what about meeting on an IRC channel to get faster turn around?

boost has irc channel? on which server? -- Janek Kozicki |

Roland Schwarz schrieb:

Could you please try to compile the examples from libs/thread/examples? We than could insert there some tracing output to confirm this suspicion.

I will do that on Wednesday.

Possibly we should do this in HEAD?

Are there significant differences between HEAD and RC in this area?

BTW.: Can you afford some more time now, or do we need to break soon? Also what about meeting on an IRC channel to get faster turn around?

Sorry, I'm squeezing this in between my regular work. And I have no idea about IRC, never used it and probably cannot use it due to FW restrictions. Markus

Markus Schöpflin wrote:

Roland Schwarz wrote:

...

Markus Schöpflin wrote:

...

What do you mean by not being available? You mean there is no threading support in this particular compiler version? Or that the threading functions are somehow broken? Somehow broken.

I found this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307

This probably explains the trouble we are seeing. I will try the patch posted in that thread and report my findings.

Applying the patch fixed the problem, the thread lib now passes all tests. I will revert the change to the Jamfile then. Markus