This is an archive of the discontinued LLVM Phabricator instance.

Correct default TimerGroup singleton to use magic-statics so that it gets cleaned up
ClosedPublic

Authored by erichkeane on Jan 5 2017, 10:42 AM.

Details

Summary

When running Valgrind, I discovered that the string in the default TimerGroup (created in getDefaultTimerGroup) gets 'possibly lost', it is never deleted in the current implementation. The TimerGroup object allocates a string, but it is stored as a pointer in getDefaultTimerGroup(), so it is never cleaned up.

This patch uses a magic-static to maintain the thread-safe behavior, however stores the value on the stack so that it gets cleaned up afterwards.

A few things:
1- The mutex that was previously created will be taken inside the DefaultTimerGroup's constructor, so there shouldn't be any concurrency problems that didn't previously exist.
2- I realize that this fix doesn't terribly matter too much, since it is cleaning stuff up right before program termination, but I thought it is a pretty minor cost for code correctness and removing the error from valgrind (reducing noise!)

Diff Detail

Event Timeline

erichkeane updated this revision to Diff 83270.Jan 5 2017, 10:42 AM
erichkeane retitled this revision from to Correct default TimerGroup singleton to use magic-statics so that it gets cleaned up.
erichkeane updated this object.
erichkeane added a subscriber: llvm-commits.

Is there a better person to review this? I believe that this is a vast improvement over the existing implementation, and should be a pretty easy to review change. Is there someone better to review this?

Are you sure that magic statics are thread-safe on all compilers we support building with?

I don't know. Is there an official list somewhere? MSVC2015, GCC4.3.

I don't know. Is there an official list somewhere? MSVC2015, GCC4.3.

The public docs look reasonable:

http://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library

Ah, I'm apparently bad at googling! According to that list, the answer is 'yes':

We use: Clang 3.1 supported since 2.9
We use: GCC 4.8 Supported since 4.3
We use: Visual Studio 2015 (Update 3), Supported since 2015
aaron.ballman accepted this revision.Feb 16 2017, 12:00 PM

Then I think this code is okay. The downside is, if it turns out there's a subtle bug, it is going to be really hard to track down.

This revision is now accepted and ready to land.Feb 16 2017, 12:00 PM
This revision was automatically updated to reflect the committed changes.
MatzeB added a subscriber: MatzeB.Feb 16 2017, 12:51 PM

Last time I wanted to add more static constructors/destructors I was yelled at in the review...