On Wed, Jul 18, 2012 at 9:59 PM, Stewart Smith <stewart@stripped> wrote:
> IF you are really lucky (or unlucky), the order in which things are
> initialized on server startup goes a bit diferent than you'd expect. I
> managed to get this to reproduce by always LD_PRELOADING
> libeatmydata. This may also occur if LD_PRELOADING other libraries, but
> I haven't tested.
> Namely, we get the Sid_map::Sid_map constructor firing before
> my_thread_global_init() is run. What happens here is that
> Sid_map::Sid_map calls a DBUG function, which will try to get a thread
> specific variable for THR_KEY_mysys, but the thread key hasn't yet been
> initialized, so instead we get a wonderful pile of garbage.
For what it's worth, I think the best thing here is to not use DBUG at
all inside constructors of static objects, let's not rely on the order
of initialization. This problems keeps popping up again and again, it
might be worth tweaking DBUG to abort if used inside a constructor.