[CORE-16773] lsan: don't report on leak:seastar::alien::message_queue#30972
Conversation
| # When running seastar_fuzz, libFuzzer's during-fuzzing leak check probes | ||
| # while the reactor is still alive and cannot trace the owning pointer through | ||
| # the blocked reactor thread's stack, so it spuriously reports the allocation. | ||
| leak:seastar::alien::message_queue |
There was a problem hiding this comment.
cannot trace the owning pointer through the blocked reactor thread's stack
what does this mean exactly? there isn't anything particularly exotic going on with reactors, i'd expect lsan to be able to handle what the alien thread is doing.
There was a problem hiding this comment.
Err good point. I kinda took the initial AI interpretation at face value.
I think the real reason is this: alien::message_queue::_pending is a boost::lockfree::queue<work_item*>, and boost::lockfree::queue uses tagged pointers to reference memory & help achieve lock free semantics. LSan does the dumb thing of scanning these tagged pointers directly (which may not point to anything initialized) during run-time, and reports false positive memory leaks.
I'm trying to find existing reports of LSan/boost::lockfree::queue having this issue, but this feels like the proper conclusion to me.
There was a problem hiding this comment.
wdyt @dotnwat? this is actively flaking in dev
lsan: don't report on leak:seastar::alien::message_queuelsan: don't report on leak:seastar::alien::message_queue
|
Did it just start happening recently? If so, then did something change? Did sanitizers get better or did we enable a new type of test or did we introduce a bug? |
the test is new, so is the way the new library |
Introduced by #30829 (commit 341302f) and observed in
v26.1.xbackport branch https://buildkite.com/redpanda/redpanda/builds/86538 - I haven't seen it reproduce ondev, but better safe than sorry.Backports Required
Release Notes