Skip to content

Fix static deinitialization fiasco in destructor#5

Closed
AngryLoki wants to merge 1 commit into
ROCm:amd-stagingfrom
AngryLoki:fix-logger
Closed

Fix static deinitialization fiasco in destructor#5
AngryLoki wants to merge 1 commit into
ROCm:amd-stagingfrom
AngryLoki:fix-logger

Conversation

@AngryLoki

Copy link
Copy Markdown

aql_profile.cpp defines:

Logger::mutex_t Logger::mutex_;

DESTRUCTOR_API void destructor() {
  Logger::Destroy();
  Pm4Factory::Destroy();
}

logger.h

  static void Destroy() {
    std::lock_guard<mutex_t> lck(mutex_);  // <--------------------- fails here
    if (instance_ != NULL) delete instance_;
    instance_ = NULL;
  }

There is no guarantees for destruction order, but in my case __attribute__((destructor)) runs after C++ destructors for static objects, trying to lock destroyed mutex.

To fix the deinitialization order, this PR removes custom destructor and replaces it with modern "Construct on First Use" idiom (a.k.a. Meyers' singletons).

Closes #4

@AngryLoki

Copy link
Copy Markdown
Author

(rebased)

@jayhawk-commits

Copy link
Copy Markdown
Contributor

Imported to ROCm/rocm-systems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Issue]: Static deinitialization fiasco in destructor

2 participants