dns: fix callback contract bug in #4307. #4346
Conversation
Previously, once the callback was posted to the dispatcher, the PendingResolution was destructed. This then broke the ability to cancel() after the post. This PR restores this capability and simplifies some of the object ownership aspects of PendingResolution post envoyproxy#4307. Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10184. Risk level: Medium (this code has scary complicated lifetime and ownership guarantees). Testing: Additional unit test and corpus entry added. Signed-off-by: Harvey Tuch <htuch@google.com>
|
@ggreenway can you take a look since you have the #4307 context? Thanks. |
|
My first thought, after glancing at the code: what about just reverting #4307 and wrapping the cares callback in a try/catch? That would be a low-risk change, and keep the code less complicated. |
|
@ggreenway if we do that, how do we safely reject the configuration? Post the exception generation back to the main thread? |
|
Sorry, I didn't mean revert all of #4307. The part that does validation earlier should remain. The rest was just adding safety for any code that throws in the future, wasn't it? If so, we can keep the safety with a try/catch, and either log it or abort() if we feel it shouldn't ever happen, or post a throw to the main thread if we really want it to hit the top-level try/catch. |
|
@ggreenway OK, I will close this out and I will switch to posting the exception only. |
Previously, once the callback was posted to the dispatcher, the
PendingResolution was destructed. This then broke the ability to
cancel() after the post. This PR restores this capability and simplifies
some of the object ownership aspects of PendingResolution post #4307.
Fixes oss-fuzz issue
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10184.
Risk level: Medium (this code has scary complicated lifetime and
ownership guarantees).
Testing: Additional unit test and corpus entry added.
Signed-off-by: Harvey Tuch htuch@google.com