axom
axom copied to clipboard
Checking if SLIC is initialized from another library erroneously returns false
There seems to be a bug in the static initialization of SLIC. When axom is linked to a standalone library, libfoo.a
and subsequently, axom and libfoo.a
are linked to a driver that initializes slic. Checking if slic is initialized inside libfoo.a
erroneously returns false.
This sounds like what I described in #29 w.r.t. linking against a Fortran application.
Thanks @kennyweiss -- I am seeing this in just C++ code. I'll investigate further.
Can we re-engineer to avoid "static" initialization? @kennyweiss do you recall any details about this issue?
Can we re-engineer to avoid "static" initialization? @kennyweiss do you recall any details about this issue?
@rhornung67 -- I think that would be a good idea!
Here's what I found:
- https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/interface/slic.cpp#L24
- https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/core/Logger.cpp#L354
- https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/core/Logger.cpp#L19
- https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/core/Logger.hpp#L338
Looks like the the latter should be marked as extern
instead of static
.
See: https://stackoverflow.com/questions/14349877/static-global-variables-in-c
Alternatively, the problem might go away if we make s_logger
a static variable in getActiveLogger()
instead of having it be a global variable in slic.
I think what is happening, due to static linking, is that there are actually multiple instances of s_Logger
: the one linked to by the main executable gets initialized, but the instance that exists for the static library is uninitialized. As long as codes use static linking, I suspect this kind of problem is unavoidable. PR #799 partially mitigates this problem: at least the libfoo.a
and all other libraries will get a minimally-configured slic, but every time a code links statically to a library that doesn't do its own slic, the code will get the warning banner added in the PR.
I'm in the process of confirming this.
It seemed like there may have been more than one Axom Slic getting initialized. But I compiled a test executable with static linking all around and was not able to reproduce the problem using C++ only. I have yet to throw Fortran into the mix.
Specifically, on Linux, C++ test application App
linked statically to Axom and to static library libtest
. Libtest
also linked statically to Axom. Initializing Slic in App
resulted in an initialized Slic in libtest
(echoing your experiences, @white238 ). Retrieving the active logger (the underlying object) from both App
and libtest
showed it has the same address (what you had previously pointed out, @kennyweiss ).
I have a feeling that even if this bug was a problem in C++ codes at one time (note @gzagaris ' comments from two years ago), it is a much smaller problem now. I don't know that this should hold up the release.
PR #870 moved the logger map and logger pointer into singletons. However, CDash testing seems to report that there is a problem with Fortran usage of SLIC loggers.
We think this is fixed. So closing. Can re-open if needed.