event loop: tolerate unexpected exceptions in post() callbacks

[hulxv]

If a function posted via EventLoop::post() threw an exception, the event loop would exit without resetting m_post_fn or notifying the condition variable, permanently deadlocking the calling thread in post().

This change catches the exception instead, logs it, and keeps the event loop running so the caller is unblocked and other I/O events continue to be processed.

Fix #259

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	ryanofsky

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

[ryanofsky]

In commit "fix: EventLoop::post() deadlocks when posted function throws" (c6ad605)

It seems like waiting for clients to be released here might just replace one deadlock with another deadlock in the general case m_post_fn throws and there is not just a single client.

I tend to think if m_post_fn is going to throws, reasonable things to do might be:

• Abort so this is detected as a bug
• Or keep executing the event loop, but log an error
• Or let the exception immediately propagate to the caller like happens currently.

Trying to propagate the exception, but waiting for resources to be freed and possibly hanging seems like it adds more complexity without providing a reliable benefit

[hulxv]

oh ok, I didn't notice that. thanks for catching it.

I tend to think if m_post_fn is going to throws, reasonable things to do might be:

* Abort so this is detected as a bug

* Or keep executing the event loop, but log an error

* Or let the exception immediately propagate to the caller like happens currently.

I think the best and simplest solution here is keeping the executing of the event loop and just log an error. what do you think?

[ryanofsky]

re: #260 (comment)

I think the best and simplest solution here is keeping the executing of the event loop and just log an error. what do you think?

Yes I think logging the exception here would be a simple improvement that should help debugging. Would recommend kj::runCatchingExceptions for that and kj::str() to turn the exception into a string.

Using catch (...) { eptr = std::current_exception(); } to catch the exception in the event loop thread and std::rethrow_exception(eptr); to rethrow it EventLoop::post() could be a different improvement that would help debugging, but I don't know if it would add too much complexity.

Keeping the event loop running after the exception is thrown should also be an improvement.

[hulxv]

done

[ryanofsky]

Code review ACK 5cf3278. Thanks for the logging improvement!

IMO it would be good to update the commit title, pr title, and PR description to clarify what this change does now, but the change itself looks good.

[ryanofsky]

Thanks for the logging improvement!

Forgot when I wrote this that this change isn't only a logging improvement, but it also changes execution because EventLoop::post will now return on failure instead of hanging, and other I/O events will now continue to be processed. Would be good to mention these things in the pr/commit description and maybe change title to something like "event loop: tolerate unexpected exceptions in post() callbacks"

[hulxv]

is there anything else that should be added?

[ryanofsky]

Code review ACK 7b26641. Thanks for the updates!

I am increasingly thinking the best thing would be for EventLoop::post to throw an exception when the callback throws an exception, instead of not returning like happens currently, or returning without failing like happens with this PR. (std::current_exception std::rethrow_exception could be useful for this.)

But It is probably not worth adding much complexity for this case since it is never expected to happen. And the logging added by this PR should at least be helpful for debugging. Just commenting to suggest possible followups.

[ryanofsky]

I was about to merge this but I see IWYU failures when building locally (I didn't notice that CI was skipped for this PR):

mp/src/mp/proxy.cpp should add these lines:
#include <kj/exception.h>       // for Exception, runCatchingExceptions

I think these need to be fixed before this can be merged.

[hulxv]

Done! Can you rerun the ci again?

[ryanofsky]

Done! Can you rerun the ci again?

Sure. Also would recommend squashing commits https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

[ryanofsky]

Code review 0dfe095. Looks like there is another CI failure https://github.com/bitcoin-core/libmultiprocess/actions/runs/23966308399/job/69937803736?pr=260. Can be fixed with:

--- a/src/mp/proxy.cpp
+++ b/src/mp/proxy.cpp
@@ -249,7 +249,7 @@ void EventLoop::loop()
             // m_post_fn throwing is never expected. If it does happen, the caller
             // of EventLoop::post() will return without any indication of failure,
             // which will likely cause other bugs. Log the error and continue.
-            KJ_IF_MAYBE(exception, kj::runCatchingExceptions([&]() { Unlock(lock, *m_post_fn); })) {
+            KJ_IF_MAYBE(exception, kj::runCatchingExceptions([&]() MP_REQUIRES(m_mutex) { Unlock(lock, *m_post_fn); })) {
                 MP_LOG(*this, Log::Error) << "EventLoop: m_post_fn threw: " << kj::str(*exception).cStr();
             }
             m_post_fn = nullptr;

[hulxv]

Can you rerun the ci again please?

[hulxv]

I think the ci failure is not related

sh: rsync: not found
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(232) [sender=3.2.7]
The process '/usr/bin/rsync' failed with exit code 12

[ryanofsky]

Code review ACK b8a48c6. Since last review just squashed commits and added missing thread safety annotation. This change is a probably an improvement from a debugging perspective since it will now always log an error when an unexpected exception happens. It is not a clear improvement in behavior since continuing after an unexpected failure could potentially be worse than hanging, but the difference is unlikely to be significant. Probably the best thing would be to catch and rethrow the exception.

Planning to merge this since the logging could be helpful