Fix packet-pool slot leak in canned message destination picker - #11017
Conversation
updateDestinationSelectionList() allocated a MeshPacket via allocDataPacket() that was never sent or released, permanently consuming one packetPool slot every time the destination-selection picker was rebuilt. On non-PSRAM targets packetPool is a static 70-slot BSS pool, so repeated picker use exhausts it and eventually blocks all packet allocation (TX/RX failures). On PSRAM/portduino (MemoryDynamic) targets it is a true heap leak of ~424B per rebuild. The allocation and its two field writes (pki_encrypted, channel) were a copy/paste artifact of the PKI setup in sendText() and had no effect in this function. Remove the dead allocation.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthrough
ChangesDestination selection cleanup
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
⚡ Try this PR in the Web FlasherNote Building this pull request… the flash button, badges and supported-board |
Summary
CannedMessageModule::updateDestinationSelectionList()allocated ameshtastic_MeshPacketviaallocDataPacket()that was never sent nor released, permanently consuming one slot frompacketPoolon every rebuild of the destination-selection picker.Impact
packetPoolis a static 70-slot BSS pool (Router.cpp:57-66). Repeated use of the destination picker steadily drains it and eventually blocks all packet allocation, causing TX/RX failures.packetPoolusesMemoryDynamic, so this is a true heap leak of ~424 B per rebuild.The picker is rebuilt on entry to destination selection, on every search keystroke, and whenever the node list changes, so the leak accumulates quickly in normal use.
Root cause
The three lines were a copy/paste artifact of the legitimate PKI setup in
sendText()(introduced in #8182, "Multi message storage"). InsendText()the allocated packet is populated and handed toservice->sendToMesh(); here it was pasted into a function that only builds a UI list and has nothing to send.Fix
Remove the dead allocation. No other code in the function references
p, so there is no behavior change beyond eliminating the leak.allocDataPacket()'s only side effect is bumping the monotonic packet-ID counter, which is harmless to skip since nothing was ever transmitted.Testing
./bin/test-native-docker.sh)trunk fmt: cleanSummary by CodeRabbit