GC freezes after 4th call

[aribeiroxyz]

Hi all,

I have a code running on a Pico2 that basically listens to the Serial and reply, nothing extraordinary. It does it often (multiple requests per second) and for a long period. Inside my code there are a few heap-allocation parts, such as Sprintf, but nothing that would make your aunt blush. Very conservative code.

I noticed that after a while (half minute) the Pico2 would stop working, and only resume when unplugging and plugging again.

After going through the basics of debugging, I decided to monitor the heap size over time (using runtime.ReadMemStats) , to check for leaks.

I could see HeapAlloc value increasing over time, untill GC kicked in cleaning my mess, and it worked as expected. But only for the first few times. After a few heap cleaning cycles (maybe 3 to 5) the microcontroler would freezing exactly when GC should be running (when HeapAlloc value was at the highest).

I followed the rabbit hole until I found this is where it is crashing:

tinygo/src/runtime/gc_stack_cores.go

Line 58 in db9f118

for gcScanState.Load() != numCPU {

for gcScanState.Load() != numCPU { // <- crashes here, in the loop part
spinLoopWait()
}

If I comment out this, code runs without a problem for hours. (Its a single core application, ter info)

How do I move forward to confirm if the problem is indeed not in my code, but something happening at this specif part of the GC?

Notice that I have no idea what I'm doing, I'm not a programmer.

With Regards,
AR

[aribeiroxyz]

A bit more of amateur-debugging:

I modified the code to add a few print statements:

println(gcScanState.Load(), numCPU)
for gcScanState.Load() != numCPU {
    println(gcScanState.Load(), numCPU)
spinLoopWait()
}

What happens is that the first few (5) iterations, when GC works fine, I get printed: '2 2'
By the next iteration, it get locked in the for loop printing '1 2' without ever changing.

[deadprogram]

The short term fix is probably to use -scheduler=tasks as discussed in several places. The next version of TinyGo will default to that on the rpxxxx chips until we get it sorted out. See #5235

[aribeiroxyz]

Your suggestion worked for me. Thanks a bunch.