Issues with setjmp/longjmp under the IDF 5+ but not Arduino (w/ IDF 4+)
Posted: Wed Oct 23, 2024 1:42 am
Hello. I'm getting the strangest issues on the ESP32 when running some setjmp/longjmp code under the ESP-IDF. The same code works under Arduino. I don't get consistent stack traces. Different devices give me different stack traces, and sometimes boot to boot i get different results. I've included one of the stack traces at the bottom though InstFetchProhibited is a new error this time around. I've been getting LoadProhibited usually, or a panic after a pointer gets corrupted with the value 0x3 instead of an actual address, and gets passed to realloc.
I should add, this is in otherwise stable, mature FreeType2 rasterizer code that was adapted for PlutoVG. It has been run through valgrind as well. There are no corruption issues or leaks. After days of debugging through process of elimination I've tracked it to setjmp longjmp in one file. I'll share that file here.
https://pastebin.com/YNsXYTRB
This code uses setjmp longjmp and I'm pretty confident that is what is causing the issue.
I can produce a full reproduction, but it includes code I can't make public yet. I have a private github repo i can add individuals to on a case by case basis for anyone who can help, and is willing to not share the code. (no NDA, just trust)
What I'd like to know is if there are any special caveats to using setjmp longjmp under the ESP-IDF that I should be aware of. I'd rather not use it at all, but it looks like it will be difficult to retool this code to avoid it.
I should add, this is in otherwise stable, mature FreeType2 rasterizer code that was adapted for PlutoVG. It has been run through valgrind as well. There are no corruption issues or leaks. After days of debugging through process of elimination I've tracked it to setjmp longjmp in one file. I'll share that file here.
https://pastebin.com/YNsXYTRB
This code uses setjmp longjmp and I'm pretty confident that is what is causing the issue.
I can produce a full reproduction, but it includes code I can't make public yet. I have a private github repo i can add individuals to on a case by case basis for anyone who can help, and is willing to not share the code. (no NDA, just trust)
What I'd like to know is if there are any special caveats to using setjmp longjmp under the ESP-IDF that I should be aware of. I'd rather not use it at all, but it looks like it will be difficult to retool this code to avoid it.
- Backtrace: 0x00006c88:0x3ffb10b0 0x40081e4f:0x3ffb10d0 0x40085199:0x3ffb1110 0x400db76d:0x3ffbe1c0 0x400db981:0x3ffbe210 0x400dbeb1:0x3ffbe280 0x400dc2d9:0x3ffbe440 0x400dc59e:0x3ffbe4b0 0x400dc821:0x3ffbe640 0x400d8701:0x3ffbf740 0x400d6f5f:0x3ffbf7a0 0x400d5070:0x3ffbf7c0 0x400d1ac9:0x3ffbf820 0x400d1ec3:0x3ffbf8d0 0x400d2f88:0x3ffbfa30
- #0 0x3ffb10b0 in _xt_exception_table at ??:?
- #1 0x40081e4f in spi_intr at C:\Users\gazto\.platformio\packages\framework-espidf\components\esp_driver_spi\src\gpspi/spi_master.c:902
- #2 0x3ffb10d0 in _xt_exception_table at ??:?
- #3 0x40085199 in _xt_lowint1 at C:\Users\gazto\.platformio\packages\framework-espidf\components\xtensa/xtensa_vectors.S:1240
- #4 0x3ffb1110 in _xt_exception_table at ??:?
- #5 0x400db76d in gray_render_scanline(TWorker_*, long, long, long, long, long) at lib/htcw_gfx/src/plutovg-ft-raster.cpp:450
- #6 0x400db981 in gray_render_line(TWorker_*, long, long) at lib/htcw_gfx/src/plutovg-ft-raster.cpp:517
- #7 0x400dbeb1 in _ZL17gray_render_cubicP8TWorker_PK7vector_S3_S3_$isra$0 at lib/htcw_gfx/src/plutovg-ft-raster.cpp:993
- #8 0x400dc2d9 in _ZL24gray_convert_glyph_innerP8TWorker_$constprop$0 at lib/htcw_gfx/src/plutovg-ft-raster.cpp:1365
- (inlined by) gray_convert_glyph_inner at lib/htcw_gfx/src/plutovg-ft-raster.cpp:1403
- #9 0x400dc59e in _ZL18gray_convert_glyphP8TWorker_$constprop$0 at lib/htcw_gfx/src/plutovg-ft-raster.cpp:1508
- #10 0x400dc821 in PVG_FT_Raster_Render(PVG_FT_Raster_Params_ const*) at lib/htcw_gfx/src/plutovg-ft-raster.cpp:1608
- (inlined by) PVG_FT_Raster_Render(PVG_FT_Raster_Params_ const*) at lib/htcw_gfx/src/plutovg-ft-raster.cpp:1623
- #11 0x400d8701 in plutovg_rasterize(plutovg_span_buffer_t*, plutovg_path const*, gfx::matrix const*, plutovg_rect const*, plutovg_stroke_data_t const*, plutovg_fill_rule_t) at lib/htcw_gfx/src/plutovg-rasterize.cpp:379
- #12 0x400d6f5f in plutovg_canvas_fill_preserve at lib/htcw_gfx/src/plutovg-canvas.cpp:674
- #13 0x400d5070 in gfx::canvas::render(bool) at lib/htcw_gfx/src/gfx_canvas.cpp:703
- #14 0x400d1ac9 in draw_clock_face() at src/main.cpp:303
- #15 0x400d1ec3 in loop() at src/main.cpp:446