BIND 10 #559: lib/log test crashes with --enable-static-link

[BIND 10 Development]

#559: lib/log test crashes with --enable-static-link
-------------------------------------+-------------------------------------
           Reporter:  jinmei         |                      Owner:  stephen
               Type:  defect         |                     Status:  new
           Priority:  critical       |                  Milestone:  R-Team-
          Component:  logging        |  Task-Backlog
          Sensitive:  0              |                   Keywords:
Add Hours to Ticket:  0              |  Estimated Number of Hours:  0
        Total Hours:  0              |                  Billable?:  1
                                     |                  Internal?:  0
-------------------------------------+-------------------------------------
 On my environment (MacOS 10.6, g++ and clang++) if I build BIND 10
 with --enable-static-link lib/log tests fail with logger_support_test
 being crashed.  After looking into it a bit closer, I found this is
 actually a more serious issue of the liblog itself.

 This is the backtrace:
 {{{
 #0  0x00007fff89143405 in std::string::_Rep::_M_dispose ()
 #1  0x00007fff89144124 in std::string::assign ()
 #2  0x0000000100000fda in std::string::_M_rep () at
 /Users/jinmei/src/isc/git/bind10/src/lib/log/root_logger_name.h:38
 #3  0x0000000100000fda in ~basic_string [inlined] () at
 logger_support_test.cc:493
 #4  ~basic_string [inlined] () at
 /Users/jinmei/src/isc/git/bind10/src/lib/log/root_logger_name.h:493
 #5  0x0000000100000fda in __static_initialization_and_destruction_0
 (__initialize_p=<value temporarily unavailable, due to optimizations>,
 __priority=<value temporarily unavailable, due to optimizations>) at
 logger_support_test.cc:38
 #6  0x00007fff5fc0d500 in
 __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
 ()
 #7  0x00007fff5fc0bcec in
 __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
 #8  0x00007fff5fc0bda6 in
 __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
 #9  0x00007fff5fc0210e in __dyld__ZN4dyld24initializeMainExecutableEv ()
 #10 0x00007fff5fc06981 in
 __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
 #11 0x00007fff5fc016d2 in
 __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
 #12 0x00007fff5fc01052 in __dyld__dyld_start ()
 }}}

 Fram #5 is at this line of logger_support_test.cc:
 {{{
 RootLoggerName root("alpha");
 }}}

 Apparently this is a typical symptom of the static initialization
 order fiasco.  In fact, if I moved the definition of "root" inside
 main(), it at least stopped crashing.  But the test still kept
 failing.

 So I looked into some other parts of lib/log, and found that it relies
 too much on statically initialized (non const) objects.  From a quick
 look, the "logger" variable defined in logger_support.cc has this
 problem.  The namespace level initialization in logger.cc and
 root_logger_name.cc seems to be dangerous, too.

 I suggest revisiting overall initialization in lib/log so that it will
 be more robust.  Since this bug can (potentially) make the application
 crash, I'd categorize it as "critical".

 I'm giving this ticket to Stephen.

 BTW, I happen to notice messagedef.h uses an unnamed namespace.  It's
 generally a discouraged practice as it can easily break the "one
 definition rule".

-- 
Ticket URL: <http://bind10.isc.org/ticket/559>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development