Mysterious failure of libboost_thread in 1_41_0
I'm trying to switch from 1_40_0 to 1_41_0, but have run into a mysterious problem in the thread lib. My test app that I used to find the problem with thread_group::interrupt_all() failed disastrously in 1_41_0. Debugging revealed that threads were being created uninterruptable. I couldn't figure out how that was happening, though. Tracing didn't show anything setting the interruptable flags to false in the threads, but they showed up that way right after the threads started. It looks like it might be some sort of memory corruption, like a write through a bogus pointer. Adding the three 1_41_0 thread library files directly to my build (and not using the library) worked fine. Using libboost_thread and the headers from 1_40_0 worked fine as well. The failure occurred when I used the 1_41_0 headers and libboost_thread. Both the static and the dynamic libs failed in exactly the same way. The only difference between the Jamfile.v2 in each version is the removal of exceptions.cpp in 1_41_0. I don't understand the build system well enough to figure out what else might have changed. I'm building using: ./bjam address-model=32 architecture=x86 threading=multi This is with OS X 10.6.2, using gcc 4.2, building a simple command-line tool. In both cases, I built the boost libraries using address-model=32, though building with 32_64 in 1_41_0 didn't make any difference. Using 32_64 was broken in 1_40_0, so I suspect that the problem might be there. If anyone wants to take a look at this, I parked the XCode project here: http://dl.dropbox.com/u/297034/ThreadTest_41.zip, 20KB. I'm sure it can be built without the XCode project, but this may be an OS X specific problem. The project is configured to use the boost version installed in /usr/local. When run, it hits an assert right after the thread starts, showing that the thread is uninterruptable. The work-around is simply to include the three files from the library directly in the project. I have to wonder if this will happen with other boost libs as well. Any help would be greatly appreciated. - Stoney -- Stonewall Ballard stoney@sb.org http://stoney.sb.org/
On Dec 6, 2009, at 10:50 AM, Stonewall Ballard wrote:
The only difference between the Jamfile.v2 in each version is the removal of exceptions.cpp in 1_41_0. I don't understand the build system well enough to figure out what else might have changed. I'm building using: ./bjam address-model=32 architecture=x86 threading=multi
you could always run bjam with -n -a and diff the output in both cases. That will tell you how the build commands differ, if at all. -- David Abrahams BoostPro Computing http://boostpro.com
On Dec 5, 2009, at 9:50 PM, Stonewall Ballard wrote:
I'm trying to switch from 1_40_0 to 1_41_0, but have run into a mysterious problem in the thread lib. My test app that I used to find the problem with thread_group::interrupt_all() failed disastrously in 1_41_0. Debugging revealed that threads were being created uninterruptable. I couldn't figure out how that was happening, though. Tracing didn't show anything setting the interruptable flags to false in the threads, but they showed up that way right after the threads started. It looks like it might be some sort of memory corruption, like a write through a bogus pointer.
Adding the three 1_41_0 thread library files directly to my build (and not using the library) worked fine. Using libboost_thread and the headers from 1_40_0 worked fine as well. The failure occurred when I used the 1_41_0 headers and libboost_thread. Both the static and the dynamic libs failed in exactly the same way.
The only difference between the Jamfile.v2 in each version is the removal of exceptions.cpp in 1_41_0. I don't understand the build system well enough to figure out what else might have changed. I'm building using: ./bjam address-model=32 architecture=x86 threading=multi
This is with OS X 10.6.2, using gcc 4.2, building a simple command-line tool. In both cases, I built the boost libraries using address-model=32, though building with 32_64 in 1_41_0 didn't make any difference. Using 32_64 was broken in 1_40_0, so I suspect that the problem might be there.
If anyone wants to take a look at this, I parked the XCode project here: http://dl.dropbox.com/u/297034/ThreadTest_41.zip, 20KB. I'm sure it can be built without the XCode project, but this may be an OS X specific problem.
The project is configured to use the boost version installed in /usr/local. When run, it hits an assert right after the thread starts, showing that the thread is uninterruptable.
The work-around is simply to include the three files from the library directly in the project. I have to wonder if this will happen with other boost libs as well.
Any help would be greatly appreciated.
- Stoney
I figured it out - defining _GLIBCXX_DEBUG causes the failure. Googling this symbol suggests that it interferes with other parts of boost because it alters the behavior of std::map, which boost::thread uses in the area where the above bug appears. This appears to be an old bug from 2004: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664 I'd have to call this a bug with std::map, but given the damage, perhaps a warning should be added to thread.cpp if this symbol is defined. I've parked a very simple one-file XCode project that illustrates the problem here: http://dl.dropbox.com/u/297034/ThreadTest_41b.zip It fails if _GLIBCXX_DEBUG is defined, and works if it isn't. - Stoney -- Stonewall Ballard stoney@sb.org http://stoney.sb.org/
On Dec 6, 2009, at 12:48 PM, Stonewall Ballard wrote:
On Dec 5, 2009, at 9:50 PM, Stonewall Ballard wrote:
I'm trying to switch from 1_40_0 to 1_41_0, but have run into a mysterious problem in the thread lib. My test app that I used to find the problem with thread_group::interrupt_all() failed disastrously in 1_41_0. Debugging revealed that threads were being created uninterruptable. I couldn't figure out how that was happening, though. Tracing didn't show anything setting the interruptable flags to false in the threads, but they showed up that way right after the threads started. It looks like it might be some sort of memory corruption, like a write through a bogus pointer.
Adding the three 1_41_0 thread library files directly to my build (and not using the library) worked fine. Using libboost_thread and the headers from 1_40_0 worked fine as well. The failure occurred when I used the 1_41_0 headers and libboost_thread. Both the static and the dynamic libs failed in exactly the same way.
The only difference between the Jamfile.v2 in each version is the removal of exceptions.cpp in 1_41_0. I don't understand the build system well enough to figure out what else might have changed. I'm building using: ./bjam address-model=32 architecture=x86 threading=multi
This is with OS X 10.6.2, using gcc 4.2, building a simple command-line tool. In both cases, I built the boost libraries using address-model=32, though building with 32_64 in 1_41_0 didn't make any difference. Using 32_64 was broken in 1_40_0, so I suspect that the problem might be there.
If anyone wants to take a look at this, I parked the XCode project here: http://dl.dropbox.com/u/297034/ThreadTest_41.zip, 20KB. I'm sure it can be built without the XCode project, but this may be an OS X specific problem.
The project is configured to use the boost version installed in /usr/local. When run, it hits an assert right after the thread starts, showing that the thread is uninterruptable.
The work-around is simply to include the three files from the library directly in the project. I have to wonder if this will happen with other boost libs as well.
Any help would be greatly appreciated.
- Stoney
I figured it out - defining _GLIBCXX_DEBUG causes the failure. Googling this symbol suggests that it interferes with other parts of boost because it alters the behavior of std::map, which boost::thread uses in the area where the above bug appears.
This appears to be an old bug from 2004: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664
I'd have to call this a bug with std::map, but given the damage, perhaps a warning should be added to thread.cpp if this symbol is defined.
I've parked a very simple one-file XCode project that illustrates the problem here: http://dl.dropbox.com/u/297034/ThreadTest_41b.zip
It fails if _GLIBCXX_DEBUG is defined, and works if it isn't.
I forgot to mention that this affects 1_41_0 but not 1_40_0. I don't know why. - Stoney -- Stonewall Ballard stoney@sb.org http://stoney.sb.org/
participants (2)
-
David Abrahams -
Stonewall Ballard