[
https://issues.apache.org/jira/browse/TS-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14323348#comment-14323348
]
Leif Hedstrom commented on TS-3392:
-----------------------------------
Hmmm, couple of things:
1) Does this not introduce a new potential race condition around the
initialization? Typically, people use pthread_once() to assure initialization
happens once, and exclusively (which has the downside of typically a lock
around the initialization code, which might be undesirable here).
2) I don't understand the reclaimable freelist code, but can we not rearrange
the dependencies in some way that the global g_mattr is initialized properly
once and for all? Can we change it such that it's initialized before (together)
with the other dependencies? There gotta be something better to do here?
3) IF we're to rewrite this, such that g_mattr is now a function, we should
drop the g_ naming convention (it's indicative of a global variable).
> 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)
