Re: [Boost-users] Mysterious failure of libboost_thread in 1_41_0

Subject: Re: [Boost-users] Mysterious failure of libboost_thread in 1_41_0
From: Stonewall Ballard (sb.list_at_[hidden])
Date: 2009-12-06 12:48:24

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_at_[hidden]           http://stoney.sb.org/