oversearch opened a new pull request #11630: URL: https://github.com/apache/pulsar/pull/11630
### Motivation This is very similar to a previous fix I submitted in commit 87ebe80. It's the same basic problem, but this class isn't part of the HandlerBase hierarchy, so it needs an independent fix. Essentially, when we create Boost ASIO timer objects from a connection pointer, they maintain a bare reference to the corresponding io_service object inside the connection object. When the destructor runs, we need to destroy the timer *before* the connection object. Keeping the correct order of these member variables is crucial to ensure we don't hit a use-after-free scenario. This was crashing some of our service code in rare circumstances, and is easily caught with Valgrind or ASAN. While I was at it, I also noticed a rather serious bug in one of the UnAckedMessageTrackerEnabled constructors: I believe the intent here was to use the c++11 "delegating constructors" feature, but I think it's written using the Java style, which doesn't work in C++ (see https://stackoverflow.com/questions/13961037/delegate-constructor-c). The semantics of the existing code would just create a new, separate UnAckedMessageTrackerEnabled on the stack in the constructor scope, then immediately destroy it! I corrected the syntax to ensure this works correctly, and fixed up the other constructor to properly use C++ initializer list syntax. Finally, I removed some dangerous c-style casts (which should *never* be used) in favor of C++ static_cast. ### Modifications Fixed the variable ordering and constructor syntax, as well as my old off-by-one bug. ### Verifying this change - [x] Make sure that the change passes the CI checks. Change is covered by existing tests, or is otherwise difficult to test. All unit tests pass. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
