Latest Boost.Threads regression results on intel-8.0-linux
All of the Boost.Threads tests for intel-8.0-linux at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/thread.html are failing, and the entire error report looks like: <quote> Compiler output: Linker output: Chmod1 ../bin/boost/libs/thread/test/test_barrier.test/intel-8.0-linux/debug/threading-multi/test_barrier Run output: EXIT STATUS: 139 </quote> Every test failing with the same error indicates a fundamental problem, but since I don't have access to the compiler or OS, I have no way of troubleshooting the problem. Any help would be appreciated. Mike
On Wed, Jul 21, 2004 at 09:33:22AM -0400, Michael Glassford wrote:
Run output:
EXIT STATUS: 139
Exit status 139 means it's signal 11 (segfault), if that helps. jon -- "The optimist believes this is the best of all possible worlds, and the pessimist fears this is so..." - H. Allen Smith
Jonathan Wakely wrote:
On Wed, Jul 21, 2004 at 09:33:22AM -0400, Michael Glassford wrote:
Run output:
EXIT STATUS: 139
Exit status 139 means it's signal 11 (segfault), if that helps.
Thanks. Unfortunately it doesn't help, because every test is failing with that same error and I don't have any way to determine why. My best guess is a configuration problem, such as the appropriate threading library not being installed. Mike
Michael Glassford wrote:
Jonathan Wakely wrote: ...
Exit status 139 means it's signal 11 (segfault), if that helps.
Thanks. Unfortunately it doesn't help, because every test is failing with that same error and I don't have any way to determine why. My best guess is a configuration problem, such as the appropriate threading library not being installed.
The tests ran successfully for the same toolset in 1.31. A missing library would result in linker errors. Regards, m
Martin Wille wrote:
Michael Glassford wrote:
Jonathan Wakely wrote:
....
Exit status 139 means it's signal 11 (segfault), if that helps.
Thanks. Unfortunately it doesn't help, because every test is failing with that same error and I don't have any way to determine why. My best guess is a configuration problem, such as the appropriate threading library not being installed.
The tests ran successfully for the same toolset in 1.31. A missing library would result in linker errors.
I was thinking of Windows, where you can link against a .lib file but must have the corresponding .dll file available at runtime. This isn't the case with Linux? Mike
On Thu, Jul 22, 2004 at 09:45:07AM -0400, Michael Glassford wrote:
The tests ran successfully for the same toolset in 1.31. A missing library would result in linker errors.
I was thinking of Windows, where you can link against a .lib file but must have the corresponding .dll file available at runtime. This isn't the case with Linux?
No, the value returned to the shell would be 1, I believe. It certainly wouldn't get signal 11. jon -- "You will find that the state is the kind of organization which, though it does big things badly, does small things badly too." - John Kenneth Galbraith
Michael Glassford wrote:
Martin Wille wrote:
Michael Glassford wrote:
...
Thanks. Unfortunately it doesn't help, because every test is failing with that same error and I don't have any way to determine why. My best guess is a configuration problem, such as the appropriate threading library not being installed.
The tests ran successfully for the same toolset in 1.31. A missing library would result in linker errors.
I was thinking of Windows, where you can link against a .lib file but must have the corresponding .dll file available at runtime. This isn't the case with Linux?
No. If you link against a .so then the .so must be available at runtime, of course. (At least for a normal linking procedure - which we're using here) Regards, m
Michael Glassford wrote:
Run output:
EXIT STATUS: 139 </quote>
Every test failing with the same error indicates a fundamental problem, but since I don't have access to the compiler or OS, I have no way of troubleshooting the problem. Any help would be appreciated.
It's a segmentation violation. I tried to create some stackdump. However, there's no helpful output, sorry. Regards, m
Chmod1
../bin/boost/libs/thread/test/test_barrier.test/intel-8.0-linux/debug/thread ing-multi/test_barrier
Run output:
EXIT STATUS: 139 </quote>
Every test failing with the same error indicates a fundamental problem, but since I don't have access to the compiler or OS, I have no way of troubleshooting the problem. Any help would be appreciated.
There's something wrong with that machine IMO: the regex, python and even the config_test tests all fail for the same reason - if someone could figure out what error 139 is we might have a chance. John.
On Wed, Jul 21, 2004 at 04:30:12PM +0100, John Maddock wrote:
Chmod1
../bin/boost/libs/thread/test/test_barrier.test/intel-8.0-linux/debug/thread ing-multi/test_barrier
Run output:
EXIT STATUS: 139 </quote>
Every test failing with the same error indicates a fundamental problem, but since I don't have access to the compiler or OS, I have no way of troubleshooting the problem. Any help would be appreciated.
There's something wrong with that machine IMO: the regex, python and even the config_test tests all fail for the same reason - if someone could figure out what error 139 is we might have a chance.
If a program exits with a signal SIG it will return 128+SIG to the shell. 139 - 128 = 11 = SIGSEGV = segfault -- "You can have my encryption algorithm, I thought to myself, when you pry my cold dead fingers from its private key." - Decrypting the Puzzle Palace, John Perry Barlow
participants (4)
-
John Maddock -
Jonathan Wakely -
Martin Wille -
Michael Glassford