Giga Crashes if using ConnectionHandler and Scheduler.h

[dansiviter]

If using the ConnectionHandler example and changing it to the following:

#include <Scheduler.h>

void setup() {
  ...
  Scheduler.startLoop(loop1);
}

void loop() {
  delay(100);  // permits yield(); to be called
}

void loop1() {
  conMan.check();
}

The Giga just crashes and get red LED flashing indicating crash. I'm raising it here as a potential issue with Scheduler.h as I tried doing effectively the same via rtos::Thread and it worked correctly:

#include "mbed.h"
using namespace rtos;

void setup() {
  ...
  thread.start(loop1);
}

void loop() {
  delay(100);
}

void loop1() {
  while(true) {
    conMan.check();
  }
}

Frankly, there is very little within Scheduler.cpp so no idea what could be causing it.

[dansiviter]

I can't seem to get useful error information as it seems it fails badly before I can extract via a Mbed Error Hook to Serial. However, I did try mbed_get_last_error_info and it was reporting the following:

Status: 0x8003010D Value: 0xFFFFFFFE
Type: 0 Module: 3 Code: 269

Which seemingly translates to MBED_ERROR_TYPE_SYSTEM, MBED_MODULE_NETWORK_STACK and TIMEOUT but may be a red herring. Again, no idea why this would be an issue due to using Scheduler.h.

[facchinm]

Hi @dansiviter ,
the problem seem to be a stack overflow; the scheduler threads override the default mbed thread stack size setting it to 1K https://github.com/arduino/ArduinoCore-mbed/blob/main/libraries/Scheduler/src/Scheduler.h#L33 .
If you increase to 4K (via Scheduler.startLoop(loop1, 4096)) everything works as expected

[facchinm]

I think the best way to tackle this would be to discourage the use of Scheduler lib (which was "ported" only to allow old sketches to run "seamlessly", but provides many more ways to shoot yourself in the foot than the normal, cooperative lib)

[dansiviter]

Thanks @facchinm, that's sorted it. Unfortunately, my codebase needs to work on some MKR boards too and using Scheduler.h makes life much simpler for 3rd party libraries that like to use delay(...) far too much. Therefore, I'd suggest a multipronged approach: modify code to correct the stack size and also put a comment in to discourage usage. Happy to submit a PR if that's a suitable approach?

[facchinm]

@dansiviter super, I'd love to merge such PR 😉