https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768
Bug ID: 72768
Summary: Potential bug about the order of destructors of static
objects and atexit() callbacks in C++?
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Created attachment 39040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39040&action=edit
The testcase in question.
Reading the ISO C++ standard,
> 3.6.4 Termination [basic.start.term]
> 3 If the completion of the initialization of an object with
> static storage duration is sequenced before a call to std::atexit
> (see <cstdlib>, 18.5), the call to the function passed to std::atexit
> is sequenced before the call to the destructor for the object. ...
Notwithstanding the vagueness of 'the completion of the initialization of an
object',
the following program:
#include <cstdlib>
#include <cstdio>
enum class state {
null,
initialized,
destroyed,
};
extern void broken_atexit();
struct global_data {
state s;
global_data()
: s(state::null)
{
std::puts("delegated constructor");
}
global_data(int)
: global_data()
{
s = state::initialized;
std::atexit(&broken_atexit);
std::puts("delegating constructor");
}
~global_data(){
s = state::destroyed;
}
} data(1);
void broken_atexit(){
if(data.s == state::destroyed){
std::puts("attempt to use a destroyed object?");
std::abort();
}
std::puts("okay");
}
int main(){
}
, when compiled with GCC, results in use of a destroyed object:
lh_mouse@lhmouse-dev:~$ g++ test.cc -std=c++11
lh_mouse@lhmouse-dev:~$ ./a.out
delegated constructor
delegating constructor
attempt to use a destroyed object?
Aborted
lh_mouse@lhmouse-dev:~$
The reason of this problem is that GCC front-end registers the dtor after
the delegating constructor returns, which is invoked before the other
callback registered inside the delegating constructor body.
The problem would be gone only if the GCC front-end registers the dtor after
the delegated constructor returns.
Is this a GCC bug?
