axom icon indicating copy to clipboard operation
axom copied to clipboard

Checking if SLIC is initialized from another library erroneously returns false

Open gzagaris opened this issue 4 years ago • 7 comments

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.

gzagaris avatar Jun 26 '20 14:06 gzagaris

This sounds like what I described in #29 w.r.t. linking against a Fortran application.

kennyweiss avatar Jun 26 '20 16:06 kennyweiss

Thanks @kennyweiss -- I am seeing this in just C++ code. I'll investigate further.

gzagaris avatar Jun 26 '20 17:06 gzagaris

Can we re-engineer to avoid "static" initialization? @kennyweiss do you recall any details about this issue?

rhornung67 avatar Mar 04 '22 21:03 rhornung67

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.

kennyweiss avatar Mar 11 '22 20:03 kennyweiss

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.

agcapps avatar Apr 01 '22 16:04 agcapps

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.

agcapps avatar Jun 06 '22 15:06 agcapps

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.

agcapps avatar Jul 27 '22 14:07 agcapps

We think this is fixed. So closing. Can re-open if needed.

rhornung67 avatar Mar 27 '23 21:03 rhornung67