logger: Create only one Context per process for mobile #38149
Conversation
The Logger::Context operates as a stack. When a new one is created, it becomes the active Context. When it gets destroyed, the destructor pops the previous Context as the currently active one. This can lead to lifetime bugs in Envoy Mobile, if multiple engines are created and the destruction of those engines lead to indeterminate destruction of the Logger::Context objects. In this commit, the behavior is changed so that the Logger::Context initialization is done by the external caller, not inside StrippedMainBase as previously done. This allows the caller, in this case, Envoy Mobile, to ensure only one Logger::Context is ever created, circumventing any potential issues on Context destruction with popping the previously saved context. Signed-off-by: Ali Beyad <abeyad@google.com>
|
/retest |
abeyad
requested review from
RyanTheOptimist,
alyssawilk and
fredyw
as code owners
|
/assign @jmarantz |
| *options_, real_time_system_, default_listener_hooks_, prod_component_factory_, | ||
| std::make_unique<PlatformImpl>(), std::make_unique<Random::RandomGeneratorImpl>(), nullptr, | ||
| create_instance, /*set_new_handler=*/false); | ||
| std::unique_ptr<Random::RandomGeneratorImpl> random_generator = |
There was a problem hiding this comment.
nit: this is a good use-case for auto as the type is obvious from context.
| // This helps avoid issues on Logger::Context destruction when the previous saved context | ||
| // could be activated in a thread-unsafe manner. | ||
| void initOnceLoggerContext(const OptionsImplBase& options) { | ||
| static Thread::MutexBasicLockable* log_lock = new Thread::MutexBasicLockable(); |
There was a problem hiding this comment.
nit: MUTABLE_CONSTRUCT_ON_FIRST_USE if we can make that work, just for consistency.
| @@ -19,6 +21,17 @@ constexpr absl::Duration ENGINE_RUNNING_TIMEOUT = absl::Seconds(30); | |||
| // Google DNS address used for IPv6 probes. | |||
| constexpr absl::string_view IPV6_PROBE_ADDRESS = "2001:4860:4860::8888"; | |||
| constexpr uint32_t IPV6_PROBE_PORT = 53; | |||
|
|
|||
| // There is only one shared static Logger::Context instance for all Envoy Mobile engines. | |||
| // This helps avoid issues on Logger::Context destruction when the previous saved context | |||
There was a problem hiding this comment.
is the essence of this problem that Envoy-Mobile does not have access to make changes in main()?
How does it handle things like ProcessWIde?
Note that ProcessWide was invented after this whole thing I did long ago with MainCommon and tbe logger context. Maybe we can lean on that more and clean some of this stuff up, so there's just one way to initalize all the things that need to be done once per process, rather than having Logger::Context be special.
What I'd like to see is most of this stuff is normally owned in main() or similar, without singletons for the most part. But if E-M is special cause it doesn't get any access to main, then there can be one ProcessWide singleton specific to E-M.
The Logger::Context operates as a stack. When a new one is created, it becomes the active Context. When it gets destroyed, the destructor pops the previous Context as the currently active one.
This can lead to lifetime bugs in Envoy Mobile, if multiple engines are created and the destruction of those engines lead to indeterminate destruction of the Logger::Context objects.
In this commit, the behavior is changed so that the Logger::Context initialization is done by the external caller, not inside StrippedMainBase as previously done. This allows the caller, in this case, Envoy Mobile, to ensure only one Logger::Context is ever created, circumventing any potential issues on Context destruction with popping the previously saved context.