[
https://issues.apache.org/jira/browse/TS-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14323501#comment-14323501
]
Bin edited comment on TS-3392 at 2/17/15 12:47 AM:
---------------------------------------------------
1) Good point. _g_mattr is only used once by ink_mutex_init. The only
possibility for a race condition is that ink_mutex_init is called concurrently
after threads are started and in C+++03 or before. In C+++11, there is
guarantee that static variables are constructed only once. See:
http://stackoverflow.com/questions/8102125/is-local-static-variable-initialization-thread-safe-in-c11.
In the enable_reclaimable_freelist situation, it is called before threads are
initialized and even before main is called.
2) Another way to go is to move the definition of _g_mattr to Arena.cc before
the definition of defaultSizeArenaBlock. C++ standard guarantees that static
variables in the same translation unit are initialized in the order they are
defined.
3) It seems that 2) is a better solution for this because it does not introduce
any risk for race conditions although the possibility for a race condition is
extremely low. I will knock up a patch.
was (Author: bzeng):
1) Good point. _g_mattr is only used once by ink_mutex_init. The only
possibility for a race condition is that ink_mutex_init is called concurrently
after threads are started and in C++++03 or before. In C++++11, there is
guarantee that static variables are constructed only once. See:
http://stackoverflow.com/questions/8102125/is-local-static-variable-initialization-thread-safe-in-c11.
In the enable_reclaimable_freelist situation, it is called before threads are
initialized and even before main is called.
2) Another way to go is to move the definition of _g_mattr to Arena.cc before
the definition of defaultSizeArenaBlock. C++ standard guarantees that static
variables in the same translation unit are initialized in the order they are
defined.
3) It seems that 2) is a better solution for this because it does not introduce
any risk for race conditions although the possibility for a race condition is
extremely low. I will knock up a patch.
> Static initialization order fiasco
> ----------------------------------
>
> Key: TS-3392
> URL: https://issues.apache.org/jira/browse/TS-3392
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Bin
> Fix For: 5.3.0
>
> Attachments: static_init_fiasco.diff
>
>
> There is a static initialization order bug in ATS core on Mac OS X when it is
> configured with --enable-reclaimable-freelist. The static variable declared
> in file Arena.cc
> static Allocator defaultSizeArenaBlock("ArenaBlock", DEFAULT_ALLOC_SIZE);
> uses another static variable x_pthread_mutexattr_t _g_mattr declared in file
> ink_mutex.cc, which have not been initialized. It causes ATS to abort early.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
