Critical bugfix for Boost.Function on 12/19
I just noticed this announcement on the Boost home page: December 19, 2007 - Critical Bug in Function Library * Boost.Function in Boost 1.34.x has a bug that affects the construction of Boost.Function objects in a multi-threaded context. The problem has been fixed in the Boost trunk and for the upcoming Boost 1.35.x. To patch your Boost 1.34.x, copy the files function_base.hpp and function_template.hpp into the Boost directory boost/function. Two questions come to mind, one technical and the other procedural: 1. What other Boost libraries make use of Boost.Function in a way that might tickle this particular bug? I'd like to understand if we are being affected by this in any way and while we aren't using Boost.Function directly, perhaps we are using it indirectly. More generally, is there a good way to understand which Boost libraries are dependent on which other libraries? 2. I can't seem to find any mention of this on the user, devel, or announce mailing lists. Is there some place besides the home page where things like this get publicized? I guess I would have expected this to come through on at least of one of those three lists. Thanks for any insights. Chad
Chad Walters wrote:
I just noticed this announcement on the Boost home page:
December 19, 2007 - Critical Bug in Function Library
* Boost.Function in Boost 1.34.x has a bug that affects the construction of Boost.Function objects in a multi-threaded context. The problem has been fixed in the Boost trunk and for the upcoming Boost 1.35.x. To patch your Boost 1.34.x, copy the files function_base.hpp and function_template.hpp into the Boost directory boost/function.
Two questions come to mind, one technical and the other procedural:
1. What other Boost libraries make use of Boost.Function in a way that might tickle this particular bug? I'd like to understand if we are being affected by this in any way and while we aren't using Boost.Function directly, perhaps we are using it indirectly.
Boost.Threads is one.
More generally, is there a good way to understand which Boost libraries are dependent on which other libraries?
2. I can't seem to find any mention of this on the user, devel, or announce mailing lists.
See: http://thread.gmane.org/gmane.comp.lib.boost.devel/167877 http://thread.gmane.org/gmane.comp.lib.boost.devel/169431
Is there some place besides the home page where things like this get publicized? I guess I would have expected this to come through on at least of one of those three lists.
FWIW, I think it would be good to get a 1.34.2 with this fix incorporated. Regards, Phil.
Phil Endecott wrote:
Chad Walters wrote:
December 19, 2007 - Critical Bug in Function Library
It's worth noting that, as I understand it, g++-generated-code won't suffer from this bug if its normal thread-safe-statics mode is in operation, i.e. if you haven't compiled with -fno-threadsafe-statics. I wasn't aware of this feature until recently. Phil.
On Mon, 2008-01-21 at 08:13 -0800, Chad Walters wrote:
1. What other Boost libraries make use of Boost.Function in a way that might tickle this particular bug? I'd like to understand if we are being affected by this in any way and while we aren't using Boost.Function directly, perhaps we are using it indirectly. More generally, is there a good way to understand which Boost libraries are dependent on which other libraries?
There isn't a good way to determine library dependencies. The obvious candidates are users of Function, Thread, Signals, or anything that depends on those. - Doug
participants (3)
-
Chad Walters -
Douglas Gregor -
Phil Endecott