Fiber lambda being optimised out?

[gjvanderheiden]

I want to use a Fiber to periodically call the lvgl event loop. It failed (crashes), it only wanted to run in a loop in main(). In the debugger I finally saw that it crashes, a var was marked as "optimized out" early on in the lvgl code. After moving the little loop code to a function and calling the loop once from the main() loop and the lambda Fiber, it works!

Is there a cleaner way to do this?

void lv_loop_fn() {
  modm::this_fiber::sleep_for(5ms);
  lv_timer_handler();
}

modm::Fiber lv_loop ([] {
  while(true) {
    lv_loop_fn();
  }
});

int main() {
  Board::initialize();
  lv_hal_init();

  // lv gui init, cut out

  // just to tell the optimiser / linker this is being called (if that is what really is going on)
  lv_loop_fn();

  modm::fiber::Scheduler::run();
  return 0;
}

[salkinium]

That's… odd, I don't have an immediate answer.

You can see the annotated dis-assembly with scons listing, so you can check directly if that function is in your executable.
You can also try the debug profile with scons program profile=debug and see if that changes things.
Or maybe there's a completely other issue that causes the crash.

[gjvanderheiden]

Ok, not a known something with Fiber. Or a apply this or that C++ macro sort of thing.
I use cmake, so a little difficult to do a scons listing. I just digged through the .elf file. I could copy the project and make it way smaller, then I can do scons listing. I already reduced the lvgl stuff to a single label with "Hello World!" on it. O well, I've got some stuff to try to see what's going on.

[salkinium]

Ah, our CMake module is missing the listing target, I'll add it later. For now you can generate it manually:

arm-none-eabi-objdump -x -S -l -w path/to/file.elf > listing.lss

[gjvanderheiden]

ok, it is not optimised out. I tried like bunch of things, but in the end, it is lvgl that crashes internally.
So how to reproduce: Any lvgl project, then use fibers to run the loop.

[gjvanderheiden]

testlvgl.zip
This is the test project I'm using. It doesn't even use a display, just a dummy.

Edit: Forgot to say that the test is as small as can be, to isolate as much as possible.

[salkinium]

Thanks for the simplified example, I was able to reproduce your exact issue.

You're running into a fiber stack overflow. This is caught by the scheduler if you implement the modm_abandon handler.

[Info]	(0.001, +1)	 lv_obj_create: begin lv_obj.c:215
[Info]	(0.001, +0)	 lv_obj_create: begin lv_obj.c:215
[Info]	(0.001, +0)	 lv_obj_create: begin lv_obj.c:215
[Info]	(0.001, +0)	 lv_obj_create: begin lv_obj.c:215
[Info]	(0.001, +0)	 lv_label_create: begin lv_label.c:125
Assertion 'fbr.stkof' @ 0x20003490 (536884368) failed!
Abandoning...

Try increasing the stack size. 2kB is enough for the simple example, but you'll likely need more for complex rendering.

modm::Fiber<1024*2> fiberLvgl([]{...});

[gjvanderheiden]

Awesome, that did the trick. Thank you also for the handler code.

Edit: kinda regret not having a serial output log. I'll try logging over stlink

[gjvanderheiden]

lvgl-linux-modm.tar.gz
I can do better at making it smaller: Linux host. Should run (well crash) without modifying. Easier to debug.

[salkinium]

Hm, I wasn't able to reproduce the issue with this one, but I'm running this on ARM64 macOS and that's using a different fiber implementation than x86. But both "only" have a 1MB default stack size, maybe that's also not enough for a hosted implementation.

[gjvanderheiden]

ok, it was just for isolating the problem anyways