BIND 10 #1698: log initialization causes real fiasco for MacOS 10.7
BIND 10 Development
do-not-reply at isc.org
Tue Feb 21 18:13:38 UTC 2012
#1698: log initialization causes real fiasco for MacOS 10.7
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: defect | Status: new
Priority: major | Milestone: Next-
Component: logging | Sprint-Proposed
Sensitive: 0 | Keywords:
Sub-Project: Core | Defect Severity: N/A
Estimated Difficulty: 0 | Feature Depending on Ticket:
Total Hours: 0 | Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
After upgrading to MacOS 10.7, the unittest for src/lib/cache starts
failing due to segfault. According to the dumped core, it seems to be
a typical symptom of the static initialization fiasco:
{{{
#0 0x00007fff95b6d950 in _malloc_initialize ()
#1 0x00007fff95b6e192 in malloc ()
#2 0x00007fff93a1768e in operator new ()
#3 0x00007fff93a0480a in std::string::_Rep::_S_create ()
#4 0x00007fff93a062fa in std::string::_S_construct<char const*> ()
#5 0x00007fff93a06412 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string ()
#6 0x000000010a8b6d49 in isc::log::Logger::Logger ()
at /Users/jinmei/src/isc/git/bind10/src/lib/log/logger.h:20
#7 0x000000010a8b6d49 in __static_initialization_and_destruction_0
[inlined]
() at /Users/jinmei/src/isc/git/bind10/src/lib/cache/logger.cc:20
#8 0x000000010a8b6d49 in global constructors keyed to
_ZN3isc5cache6loggerE ()
at logger.cc:24
}}}
In fact, if I did this it worked again:
- make cache/logger.cc empty (not to statically initialize 'logger')
- add the following cache_messages.cc:
{{{#!c++
isc::log::Logger&
getLogger() {
static const isc::log::MessageInitializer initializer(values);
static isc::log::Logger logger("cache");
return (logger);
}
}}}
and remove the static initialization of "initializer".
- replace any reference to the 'logger' variable to a call to
getLogger().
In my environment this type of fiasco only happened with this library,
but in theory there should be no reason it cannot happen for others.
I think it's now time to make the framework safer. The indirect
access via the proxy function like getLogger doesn't look nice, but
basically something like this is the only guaranteed way to avoid the
fiasco. We can only pray for luck with other ways, and,
unfortunately, it's proven we are not that lucky.
--
Ticket URL: <https://bind10.isc.org/ticket/1698>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list