How to deal with "exit-time destructor" warning in clang?

24,853

Solution 1

Global and function static objects will get their destructors called when your application is exiting. these destructors are "exit time destructors". and are called in the reverse order that they were constructed in.

As you said, if some of these destructors touch already destroyed objects, your program could crash. Also, destructors running at exit time will make the program exit slower, and most of the time they are not necessary for the correctness of the program (since when the program exits, it'll release all its memory anyway).

The warning is simply pointing out that you have destructors that'll be run at exit time.

The fix you proposed will heap allocate the object, which will not cause it to be automatically destroyed at program exit. For your case, this is probably good enough.

Solution 2

See attributes no_destroy/always_destroy https://clang.llvm.org/docs/AttributeReference.html

Share:
24,853
Lars Schneider
Author by

Lars Schneider

Passionate software engineer. Perfectionist in software architecture, yet pragmatic with implementation. Generalist. Problem solver. http://www.linkedin.com/in/lschneider http://www.youtube.com/user/kit3bus https://github.com/larsxschneider

Updated on February 11, 2021

Comments

  • Lars Schneider
    Lars Schneider about 3 years

    In my C++11 code I get the clang warning "Declaration requires an exit-time destructor" in the following case:

    static const std::map<int, const someStruct> mymap = {
        {1, {
            "A",
            "B",
            "C"
        }},
        {2, {
            "D",
            "E",
            "F"
        }}
    };
    

    As far as I understand Google an "exit-time destructor" is required to destroy main() and statics in a deterministic way to prevent crashes on exit due to "already released variables". Is that right? Can someone explain it better?

    Plus: What can I do about it (I don't want to disable the warning)? The code above is used within context of one thread only.

    Looks like this is the way Chromium deals with these cases; would that be the right way for my case as well?

    #define CR_DEFINE_STATIC_LOCAL(type, name, arguments) \
      static type& name = *new type arguments
    

    (Source: https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/base/basictypes.h)

  • Konrad Rudolph
    Konrad Rudolph over 11 years
    Depending on what someStruct’s destructor does. I’m generally wary of preventing destructors from being run. Managing memory might not be an issue any more at program exit, but other non-trivial operations might have to run nevertheless. In a more complex scenario it quickly becomes hard to prove that not running destructors has no averse effect. Furthermore, the slowdown at program exit is noticeable only when large portions of memory get released.
  • yiding
    yiding over 11 years
    Yep, that's why i say "probably" and "most of the time". If your destructors interact with the rest of the system via some sort of IO, then you want these destructors to run. A simple example would be a global configuration object which saves the settings to disk when the program is quitting, and you rely on the destructor to know when that happens (not that I advocate for code that does this).
  • Lars Schneider
    Lars Schneider over 11 years
    @KonradRudolph The struct is three "const char *". Therefore my co-worker rightly objects that heap allocation is overkill. Is there any way to make this warning free without heap allocation?
  • yiding
    yiding over 11 years
    I think it's complaining about the std::map, rather than the structs inside it.
  • Lars Schneider
    Lars Schneider over 11 years
    @yiding True. But is there anything I can do about it besides the heap allocation #define in my question?
  • thesaint
    thesaint almost 11 years
    You should just let the profiler tell you this stuff and disable the warning. It is not even in pedantic, after all.
  • Svend Hansen
    Svend Hansen about 3 years
    Would it be correct to edit the last paragraph to say "which will cause it to not be automatically destroyed"? It's not to be pedantic, but because it changes the meaning of the sentence a bit, and I want to make sure I understand it correctly :)