search

ivmarkov / rust-esp32-std-demo

Rust on ESP32 STD demo app. A demo STD binary crate for the ESP32[XX] and ESP-IDF, which connects to WiFi, Ethernet, drives a small HTTP server and draws on a LED screen.
Apache License 2.0
784 stars 107 forks source link

problem in test_threads() #45

Closed androbi-com closed 2 years ago

androbi-com commented 2 years ago

Hi, I have been able to compile and run this demo on a ESP32, however it only works when I comment out the test_threads() call. With test_threads() I get

Rust main thread: Thread { id: ThreadId(1), name: Some("main"), .. }
Main TLS before change: 13
Main TLS after change: 42
This is thread number 1, Thread { id: ThreadId(3), name: None, .. }
This is thread number 0, Thread { id: ThreadId(2), name: None, .. }
Inner TLS: 1

abort() was called at PC 0x40082863 on core 0

and the ESP32 reboots. Playing around a bit with the code, the crash seems to occur in the join which mentions a patch in the code. I am not sure if this is due to an incorrect install of the toolchain from my side? On startup the ESP prints ESP-IDF: 4.3.1. I have seen this closed issue for esp-idf and am not sure if the mentioned patch is included in my version. I am aware of the same issue on the ESP-C3, but to my understanding these use are different compiler. If the issue is the same please close my current issue.

fusetim commented 2 years ago

I'm currently in the same situation and wondering what are these patches mentioned.

lkoba commented 2 years ago

Please take this with a grain of salt because I'm not familiar with this build toolchain and only through unholy rituals I figured out that it seems that esp32-idf-sys does include the patch but platformio's build process isn't applying it for some reason.

This produces a working build for me:


# first of all, setup everything required to produce a crashing build. if you haven't reached that part this won't work either.

# clean everything.
cargo clean
rm -fr .embuild

# run a build to regenerate .embuild and apply the patch manually.
cargo build 

# do it!
cat target/*-espidf/debug/build/esp-idf-sys-*/out/esp-idf/patches/pthread_destructor_fix.diff | patch -p1 -d .embuild/platformio/packages/framework-espidf

# force rebuild of the base library. this won't delete our patched .embuild.
make clean 

# final build. flash this one.
cargo build
androbi-com commented 2 years ago

Great, thanks a lot, this works for me. Your make clean should be a cargo clean of course. I have also been using the following template for generating a base project

cargo generate --vcs none --git https://github.com/esp-rs/esp-idf-template cargo

I have now checked that with this template the patch is applied (and thread join is working), but I am not familiar enough with the toolchain to find out what the difference between the two setups is.

ivmarkov commented 2 years ago

Thanks for the research. Once I'm back I'll check why the patch does not apply cleanly and fix.

ivmarkov commented 2 years ago

The patch does not apply simply because in recent PlatformIO they've changed the esp-idf copy they distribute to no longer be a true git repo. I.e., .platformio/packages/framework_espidf no longer has a .git subfolder.

As a result, git apply simply does not work. Worse, it just skips the patch (which you can only see if you run it in verbose mode), but returns exit code 0 as if all is fine.

The only workaround I've found so far is to temporarily run git init before git apply, and this is what I'm about to implement as a workaround.

As for why not using patch instead, as suggested above - patch is not available on Windows out of the box, while git very likely is...

ivmarkov commented 2 years ago

OK so there is a new release 0.27.1 of embuild which should fix the issue. To switch to it, do the following: