Only call ares_library_init()/cleanup() routines in process_wide() if ares extension used in DNS resolving. #21884
Conversation
… ares extension is linked in. Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
yanjunxiang-google
requested review from
yanavlasov and
mattklein123
as code owners
|
/assign @jmarantz @yanavlasov @mattklein123 |
|
per IM I am not seeing how this can work. |
With c-ares library is an extension now, this change helps fixing a bug that if someone build Envoy with c-ares is not linked in here, : , the ares_library_init()/ares_library_cleanup() should not be called.This is not an issue before since ares library is in core. It is a minor issue now since ares extension is by default included. |
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Thanks for the comments. Please take a look the latest fix. The latest fix will only call ares_library_init() when the createDnsResolver() is called for c-ares. And it will only call ares_library_cleanup() during ~process_wide() when c-ares createDnsResolver() is ever called. Overall, this PR can help that if c-ares extension is not linked in, or even is linked in but never used due to configuration, ares_library_init()/ares_library_cleanup() will not be called. |
| void cleanup() override { | ||
| // Cleanup c-ares library if initialized. | ||
| if (ares_library_initialized_) { | ||
| ares_library_cleanup(); |
There was a problem hiding this comment.
Can we move this cleanup to the ares factory destructor? That would feel a little cleaner.
There was a problem hiding this comment.
Can't do it in the destructor since factories are statically initialized and will race with whatever static clean-up happens in c-ares.
There was a problem hiding this comment.
Makes sense. Can you comment that the destructor is not called in deterministic order as the object is statically constructed.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
|
/wait |
yanjunxiang-google
changed the title
| void cleanup() override { | ||
| // Cleanup c-ares library if initialized. | ||
| if (ares_library_initialized_) { | ||
| ares_library_cleanup(); |
There was a problem hiding this comment.
Can't do it in the destructor since factories are statically initialized and will race with whatever static clean-up happens in c-ares.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
| void cleanup() override { | ||
| // Cleanup c-ares library if initialized. | ||
| if (ares_library_initialized_) { | ||
| ares_library_cleanup(); |
There was a problem hiding this comment.
Makes sense. Can you comment that the destructor is not called in deterministic order as the object is statically constructed.
|
/wait |
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
|
/wait |
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
|
/wait |
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
Thanks jmarantz@ for the comments and approval! |
…`. (#877) Also re-enable `text_gcc`. Fixes #872. **Details**: - `ServiceImpl` creates `Envoy::Logger::Context` which requires `Envoy::Thread::MutexBasicLockable`. - The `Envoy::Thread::MutexBasicLockable` was constructed after the `Envoy::Logger::Context`, so `Envoy::Logger::Context` became invalid during destruction of `ServiceImpl`. - this PR ensures that `Envoy::Thread::MutexBasicLockable` lives longer than `Envoy::Logger::Context`. - Fixing the same problem in the construction of `RequestSourceServiceImpl`. **Reason for `test_gcc` failure:** - envoyproxy/envoy#21884 triggered this bug, because it added a logging call initiated indirectly from the destructor of `Envoy::ProcessWide`. - This logging call happened during the destruction of `ServiceImpl` when the `Envoy::Thread::MutexBasicLockable` instance was already destroyed. - As a result the PURE virtual methods on its parent object `Envoy::Thread::BasicLockable` were called. - `test_gcc` reported it because it places a special function meant to detect this behavior in the `vtbl` of unimplemented pure virtual methods. Signed-off-by: Jakub Sobon <mumak@google.com>
Only call ares_library_init()/cleanup() routines in process_wide() if ares extension is used in DNS resolving.
Signed-off-by: Yanjun Xiang yanjunxiang@google.com
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]