[BUG] [TC-DGSW-2.3] CurrentHeapUsed value is greater than CurrentHeapHighWatermark value.

[KishokG]

Reproduction steps

1. Bring up the DUT with All-clusters-app.
2. Pair the DUT using chip-tool through "Onnetwork" transport.
3. Test Step 4: Run the command ./chip-tool softwarediagnostics read current-heap-high-watermark 1 0.

DUT Response:

[1726649946.746] [4516:4518] [TOO] Endpoint: 0 Cluster: 0x0000_0034 Attribute 0x0000_0003 DataVersion: 1169312532 [1726649946.746] [4516:4518] [TOO] CurrentHeapHighWatermark: 729744

5. Test Step 5: Run the command ./chip-tool softwarediagnostics read current-heap-used 1 0.

Expected DUT Response: CurrentHeapUsed value is less than or equal to CurrentHeapHighWatermark value.

Actual DUT Response:

[1726649951.863] [4520:4522] [TOO] Endpoint: 0 Cluster: 0x0000_0034 Attribute 0x0000_0002 DataVersion: 1169312532 [1726649951.863] [4520:4522] [TOO] CurrentHeapUsed: 730384

Bug prevalence

Whenever I try to read CurrentHeapUsed.

GitHub hash of the SDK that was being used

17b1a38e909e7874593bcb87c31be03a5866f1d4

Platform

raspi

Platform Version(s)

RPI - 4, 8GB RAM

Anything else?

Log file: TC-DGSW-2.3.txt

Test Plan Reference: https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/cluster/software_diagnostics.adoc Specification Reference: https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DiagnosticsSoftware.adoc#ref_SoftwareResetWatermarks

[bzbarsky-apple]

@KishokG That does not look like a valid test: more memory could have been allocated between step 4 and step 5, so heap used might be larger than the old high watermark value. The only valid way to test this is to read heap used first, then read the watermark and make sure the watermark is no less than the used value that was already seen.