test: drain toPhoneQueue in MQTT test to fix ASan leak

sendLocal() now dispatches local packets through handleReceived() directly
instead of the mock-overridden enqueueReceivedMessage(). The MQTT implicit
ACK-to-self therefore runs the full receive pipeline (RoutingModule ->
MeshService::handleFromRadio -> sendToPhone), enqueuing pooled MeshPacket
copies into toPhoneQueue. Production drains that queue via PhoneAPI, but the
test has no phone reader, so the copies leaked at teardown (LeakSanitizer:
42824 bytes / 101 objects across test_receiveFuzzServiceEnvelope and
test_receiveAcksOwnSentMessages).

Give MockMeshService a destructor that drains toPhoneQueue like the phone
would. Test-only; the real firmware does not leak here.
This commit is contained in:
Ben Meadors
2026-07-21 05:27:23 -05:00
parent 1317176f78
commit e247f70c6d
+9
View File
@@ -53,6 +53,15 @@ class MockRouter : public Router
class MockMeshService : public MeshService
{
public:
// No PhoneAPI reader exists in these tests, so packets the receive pipeline forwards to the phone
// (MeshService::sendToPhone enqueues pooled copies into toPhoneQueue) would leak at teardown. Drain
// the queue like the phone would. This surfaced once sendLocal() began dispatching local packets
// through handleReceived() directly rather than via the (mock-overridden) enqueueReceivedMessage().
~MockMeshService()
{
while (meshtastic_MeshPacket *p = getForPhone())
releaseToPool(p);
}
void sendMqttMessageToClientProxy(meshtastic_MqttClientProxyMessage *m) override
{
messages_.emplace_back(*m);