Re: [Adonthell-devel] Compile error

[Kai Sterker]

On Sat, Mar 19, 2011 at 9:28 PM, Josh Glover <address@hidden> wrote:

> However, paths::init is also called twice without userdatadir, and
> that is causing the problem. The first one happens *before* main::main
> runs! The second time seems to lead to the segfault. The stack trace
> follows.

paths::init does get run twice here too, something I wanted to correct
for ages, but always pushed off as it didn't seem to do any harm.
Guess it's time to look into it now, though hard to say why it fails
all of a sudden. Changes in the C runtime, perhaps.

> I can't understand what is going on here--what are "global
> constructors"? Are there some global variables somewhere that are
> getting initialised before main? And if so, why are they used in that
> uninitialised state, before the user data dir from main is applied?

Global constructors are just that. If you look at base.cc, there are
global timer and path instances. Those get constructed when the base
lib is loaded, even before the call to main. Now if you look at
paths.cc, you'll see that the path constructor calls init without game
and "." as user data directory. I imagine that's where those
additional calls to paths::init occur.

If things work out okay, I would expect the first call on startup with
the empty arguments, the second (and last) in app::init with the
proper command line args. Now, from what you write and the stacktrace,
it appears there is a 3rd call that happens when the base python
module is loaded. That is strange, as it should just use
libadonthell_base.so that is already present in memory, but it looks
like its loading a fresh copy.


> Any ideas what could be happening here? It is so odd, since HEAD
> obviously builds and works for you...

I guess for a start, you could try removing the paths::init call in
paths::paths. You still might end up with an uninitialized copy,
though, if libadonthell_base is loaded twice. That's really something
that shouldn't happen.

At any rate, it may not be the best practice to rely on global
constructors when dealing with multiple dynamic libraries, as there's
no guarantee on the order of initialization. Long ago, there was a
similar issue with the event stuff, where static methods would be
called (from other modules) before the static objects in the event
module had been initialized.

  See  
http://lists.nongnu.org/archive/html/adonthell-devel/2005-09/msg00000.html
  and  http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.15

Maybe a similar idiom could be employed for base::Paths (and base::Timer) too.

Kai