-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial Print Deadlock with Multicore #7
Comments
Thanks, I will check out it later in the debugger on why it locks up / what state it is in. |
That would be awesome thanks! |
In the new platform integration (platformio#36), PicoProbe debugging works with both ArduinoCore-mbed and Arduino-Pico as the used Arduino core. And I've also tested that this works with both cores, so if one core hits a breakpoint (or I just press the pause button), I see the exact execution state of both cores. |
That sounds very good. I think I'll look into it over the weekend. |
I can repro the failure locally using PIO and the latest integration (just replaced the platform.ini with the lines given in that PR). Both the RAM and flash sizes are different from when built in the IDE under any optimization option. I would expect flash sizes to differ w/optimization, but the RAM used normally does not change as those are simply global vars which are invariant to optimization levels. I'm still learning PIO so I'll try to get the actual compile and link commands and see what differences I find (but no guarantees...only times I've used P.IO is for building Marlin and it was just "hit return") |
I can really recommend PIO. I love it more every day I use it. I'll try to get into step-by-step debugging with SWD and Pico Probe. maybe ill find the spot where it gets stuck. @maxgerhardt what are the default optimization settings in PIO ? maybe the mutex's are copied inline. but that doesn't really explain the freez |
What I see with the debugger: After 2 iterations, the second core gets into a hardfault while trying to de-allocate a String object. Not yet sure why. Maybe the |
The faulting instruction is a load-into-register instruction with the source being r7 + 4, but the r7 register is pointing at 0x4db85158, is that even valid RAM? Heap corruption when the heap is concurrently used by e.g. the String functions? Are heap free() and malloc() function guarded by a mutex and threadsafe? Well GDB definitely can't read from that memory address..
|
Some GOOG and some The PIO build is running without any default optimization. The IDE uses All tested optimization levels work in the IDE except for So, looks to be not PIO related, just GCC optimization and the core related. No idea what specifically at this point, but a simple workaround: add |
Also, the RAM and FLASH size differences are not real, just PIO accounting for things differently than the IDE's |
I can confirm that with the latest version, by default there is indeed no
(Cut out includes for brievity) |
I can confirm that the first tests with I'll run some more tests later! |
Patched by earlephilhower/arduino-pico#619. However, it leaves a bad feeling: When compiling with Default optimization is correct and should be done, but there might be a sleeper cell here that might blow up later. With optimization it might only reduce the chances of it happening, not fully eliminating it. |
The |
If i understand correctly: The String variable becomes out of scope and is deleted, but the Serial write function is still using the object (and not a copy of it) Every copying in the logfunction would thus only move the scope around a bit but change not the problem itself |
No, that can't be the case here. The I think @maxgerhardt was thinking there might be a multithreaded unsafe |
In any case, let's move this back to earlephilhower/arduino-pico#614 as it is not platform.io related. |
There really is a race condition that is unprotected.
I need to see if I broke the |
Protect against heap corruption by mutex-protecting the realloc() call (like malloc/free are already). Fixes raspberrypi#863 Fixes maxgerhardt/platform-raspberrypi#7 Fixes earlephilhower/arduino-pico#614
This can be closed. Latest pico-sdk has the patch applied while the full patch is a PR in the RPi repo. |
Ah very nice! When will the latest pico-sdk be updated into the core? |
The latest master has the patch already, and it'll go out to everyone on 1.3.2 (whenever the RPi team releases and assuming they accept it). Update and you should be good to go. |
Protect against heap corruption by mutex-protecting the realloc() call (like malloc/free are already). Fixes #863 Fixes maxgerhardt/platform-raspberrypi#7 Fixes earlephilhower/arduino-pico#614
Hi,
Ive found a Problem that seems to only happen with the PIO core and not with the Arduino Version.
The original issue (here) I opened in the earlephilhower/arduino-pico was closed.
I tested the code on multiple Windows 10 PCs with the same result
Here the relevant code. I've reduced the Pio project to its minimum
Demo_RP2040_Deadlock_Clean.zip
and this is the ulf that i get and doesn't work:
firmware.zip
As it works with Arduino IDE and not with PIO, might this be caused by optimization?
The text was updated successfully, but these errors were encountered: