You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that with the current way that mlogger is managed by a unique_ptr, it can lead to crashes when trying to log in destructors that stem for static data, since that mlogger might already have been destroyed.
I was wondering what your opinions are on having it leak until the application is destroyed. I've made this modification locally and it allows me to log in some really deep parts of my project, but of course it will show up on a leak tool like valgrind. I've always been of the opinion that this is one exception to the rule, anyway. Here's the commit if your interested.
The text was updated successfully, but these errors were encountered:
I noticed that with the current way that mlogger is managed by a unique_ptr, it can lead to crashes when trying to log in destructors that stem for static data, since that mlogger might already have been destroyed.
I was wondering what your opinions are on having it leak until the application is destroyed. I've made this modification locally and it allows me to log in some really deep parts of my project, but of course it will show up on a leak tool like valgrind. I've always been of the opinion that this is one exception to the rule, anyway. Here's the commit if your interested.
The text was updated successfully, but these errors were encountered: