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
{{ message }}
This repository has been archived by the owner on Jul 13, 2023. It is now read-only.
When dropped, slog_scope's logger guard resets the global logger to 'NoGlobalLoggerSet' which panics on log messages. We introduced reset_logging in b2132f to avoid potential panics during tests but they can still occur (especially when compiled in debug mode which can enable more verbose logging in our support libs).
I think I'm seeing drop of this guard happen after our reset_logging is called. I'm not sure why, maybe because of our tie ins on the Python side, see the cffi ffi.gc calls.
I've also seen a random lazy_static! block initialize something in a thread that triggers panics. Long story short: they're difficult to avoid, so let's disable the guard for now and report this issue to slog_scope as bad behavior.
The text was updated successfully, but these errors were encountered:
When dropped, slog_scope's logger guard resets the global logger to 'NoGlobalLoggerSet' which panics on log messages. We introduced reset_logging in b2132f to avoid potential panics during tests but they can still occur (especially when compiled in debug mode which can enable more verbose logging in our support libs).
I think I'm seeing drop of this guard happen after our reset_logging is called. I'm not sure why, maybe because of our tie ins on the Python side, see the cffi ffi.gc calls.
I've also seen a random lazy_static! block initialize something in a thread that triggers panics. Long story short: they're difficult to avoid, so let's disable the guard for now and report this issue to slog_scope as bad behavior.
The text was updated successfully, but these errors were encountered: