BIND 10 #1698: log initialization causes real fiasco for MacOS 10.7

[BIND 10 Development]

#1698: log initialization causes real fiasco for MacOS 10.7
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:         |             Milestone:  Next-Sprint-
  defect                             |  Proposed
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by stephen):

 It does look as if the crash is in the static initialization of Logger().
 However, Logger uses the pimpl idiom, with the implementation class not
 instantiated until the first time Logger is used; all Logger holds is a
 string storing the name of the logger, and that is constructed when Logger
 is constructed.  I'm surprised by the crash - I can only think that
 somehow the memory allocation code is not properly initialized at the time
 the program runs.

 Does replacing:
 {{{
 std::string name_;
 }}}
 with something like
 {{{
 char name_[16];
 }}}
 ... and copyying the name with which the logger is instantiated to name_
 in the constructor solve the problem? (Obviously there would need to be
 appropriate checks as to the length of the string; however, most logger
 names are less than 15 characters long.)

 With regards to
 > and remove the static initialization of "initializer".
 "initializer" is more a namespace than anything else - the class
 !MessageInitializer has no member attributes of its own.  The constructor
 adds the values passed in the constructor argument to the singleton global
 message dictionary.  The dictionary is obtained via a call to a function
 that holds it as a static variable (in much the way as the suggested
 getLogger() code does.)  However, I will concede that if there are some
 operating systems where system libraries are not fully initialized before
 control is transferred to user code, all bets are off.

 I'd be loath to remove the static initialization if we can avoid it
 because a long-term intention of the logger was to allow users to load
 their own messages at sratup time, replacing messages already there.
 Deferring the initialization of the message dictionary until the first
 time a message is logged means that we can't check that the IDs in the
 user message list are correct at startup.

 On the other hand, the suggested code does couple the messages to the
 logger used to log them (cache_messages.cc is generated from
 cache_messages.mes) and given recent discussions of what documentation we
 give to users about what loggers they need to enable to get particular
 messages, that may be no bad thing.

 > We can only pray for luck with other ways, and, unfortunately, it's
 proven we are not that lucky.
 I think that's a bit extreme - we test on a number of systems and have not
 had a problem, and none of our users have reported anything similar.  And
 although C++ does have an issue with the static initialization fiasco,
 static initialization is a useful tool.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1698#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development