Crossbeam-channel deadlocks when cap = 0

[Erhannis]

I'm not sure who to file this report with, haha, but here seemed like the most correct, AFAICT.
I cloned https://github.com/ivmarkov/rust-esp32-std-demo and got that working, which was nice. I then made a few modifications, and got those to work. As I started with something more complicated, I wanted CSP-like channels, so I added the crossbeam-channel dependency, and I copied in their fibonacci example. Then I had some problems, which I've so far narrowed down to: on an ESP32, channels block forever if the channel cap is 0. I compiled the example in a new project targeting my laptop and it ran fine with a cap of 0 or 3, but on ESP32 it permablocked with a cap of 0 but worked with a cap of 3. This suggests to me it's some bug in the ESP Rust code, or at least some kind of incompatibility. Any idea what's wrong? If, after inspection, you're confident the problem is somewhere else, let me know where I should send the bug report.

My modified version of the code can be found at https://github.com/Erhannis/rust-esp32-std-demo/tree/hack . See this function.

Here's the log when the code blocks, (slightly annotated) :

(... finishing the threads test:)
About to join the threads. If ESP-IDF was patched successfully, joining will NOT crash
Inner TLS: 4
Main TLS after threads: 42
Joins were successful.
(going into the csp test:)
--> test_csp
--- test_csp 1
--- test_csp 2
--> test_csp.fibonacci
--- test_csp 3
E (14904) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (14904) task_wdt:  - IDLE (CPU 0)
E (14904) task_wdt: Tasks currently running:
E (14904) task_wdt: CPU 0: pthread
E (14904) task_wdt: CPU 1: IDLE
E (14904) task_wdt: Print CPU 0 (current core) backtrace

Backtrace: 0x40185DEE:0x3FFB0EE0 0x40082DF1:0x3FFB0F00 0x4008A53D:0x3FFC0C70 0x40160319:0x3FFC0C90 0x401400EA:0x3FFC0CB0 0x401463AA:0x3FFC0CF0 0x400DEBEF:0x3FFC0D10 0x400DF2B6:0x3FFC0D30 0x400DF0D7:0x3FFC0D60 0x400DF642:0x3FFC0DE0 0x400E2563:0x3FFC0EA0 0x400D9EE5:0x3FFC0EE0 0x400D5C12:0x3FFC0F50 0x400E1C97:0x3FFC0F70 0x40135E77:0x3FFC0FA0 0x40135ECE:0x3FFC0FC0 0x401400DC:0x3FFC0FE0 0x40160308:0x3FFC1000
E (14904) task_wdt: Print CPU 1 backtrace
Backtrace: 0x40084C5D:0x3FFB14E0 0x40082DF1:0x3FFB1500 0x4000BFED:0x3FFBF920 0x4008B336:0x3FFBF930 0x40186057:0x3FFBF950 0x40186063:0x3FFBF980 0x40161622:0x3FFBF9A0 0x40089450:0x3FFBF9C0
(Watchdog triggers again a few seconds later; repeat.)

If I set cap to 3 (presumably anything greater than zero), it works fine:

(... finishing the threads test, as before:)
About to join the threads. If ESP-IDF was patched successfully, joining will NOT crash
Inner TLS: 4
Main TLS after threads: 42
Joins were successful.
(going into the csp test, again:)
--> test_csp
--- test_csp 1
--- test_csp 2
--> test_csp.fibonacci
--- test_csp.fibonacci loop 0 1
--- test_csp.fibonacci loop 1 1
--- test_csp.fibonacci loop 1 2
--- test_csp 3
--- test_csp.fibonacci loop 2 3
0
--- test_csp.fibonacci loop 3 5
1
--- test_csp.fibonacci loop 5 8
1
--- test_csp.fibonacci loop 8 13
2
--- test_csp.fibonacci loop 13 21
3
--- test_csp.fibonacci loop 21 34
5
--- test_csp.fibonacci loop 34 55
8
--- test_csp.fibonacci loop 55 89
13
--- test_csp.fibonacci loop 89 144
21
--- test_csp.fibonacci loop 144 233
34
--- test_csp.fibonacci loop 233 377
55
--- test_csp.fibonacci loop 377 610
89
--- test_csp.fibonacci loop 610 987
144
--- test_csp.fibonacci loop 987 1597
233
--- test_csp.fibonacci loop 1597 2584
377
--- test_csp.fibonacci loop 2584 4181
610
--- test_csp.fibonacci loop 4181 6765
987
--- test_csp.fibonacci loop 6765 10946
1597
--- test_csp.fibonacci loop 10946 17711
2584
--- test_csp.fibonacci loop 17711 28657
4181
--- test_csp 4
<-- test_csp 5
<-- test_csp.fibonacci
(this time the test finishes correctly and the code continues on to the other tests)

Meta

I'm using an ESP32 dev board - on the back of the board it says "ESP32 DEVKITV1.", and on the chip cover it says "ESP-WROOM-32", and some other numbers?
rustc --version --verbose:

rustc 1.65.0-nightly (5b08d0476 2022-11-04)
binary: rustc
commit-hash: 5b08d0476812477a954614d8f7a20f3fd527185e
commit-date: 2022-11-04
host: x86_64-unknown-linux-gnu
release: 1.65.0-nightly
LLVM version: 15.0.0

[MabezDev]

Hi there, sorry for the delay! Would you mind trying again with the 1.69 release? I believe this may now be fixed.

[Erhannis]

Hmm. It's been a while since I messed with this, but consulting the instructions, I tried updating everything and running again. I think I ran cargo install espup and espup install, and my rustc --version --verbose reads

rustc 1.69.0-nightly (e7a099116 2023-04-17) (1.69.0.0)
binary: rustc
commit-hash: e7a0991164b497f97a9af93183eb4ea51d0f5c48
commit-date: 2023-04-17
host: x86_64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.0

(I've also run . ~/export-esp.sh as instructed.)

However, I've cloned a clean copy of https://github.com/ivmarkov/rust-esp32-std-demo , and I'm getting an error at the end of cargo run that I don't know how to follow. Here's the log (with the middle cut out).

~/clones/rust-esp32-std-demo_clean$ cargo run
   Compiling compiler_builtins v0.1.87
...
   Compiling url v2.3.1
   Compiling mipidsi v0.5.0
    Finished dev [optimized + debuginfo] target(s) in 4m 02s
     Running `target/xtensa-esp32-espidf/debug/rust-esp32-std-demo`
target/xtensa-esp32-espidf/debug/rust-esp32-std-demo: 1: Syntax error: "(" unexpected

(I can add the middle back in if you want, but it looks like just a bunch more of the same.)

I'm not sure what to do with this; it looks like an error in an unnamed script file rather than an error in the named file, since that one is a binary, not a source, and I can't run it directly because

~/clones/rust-esp32-std-demo_clean$ target/xtensa-esp32-espidf/debug/rust-esp32-std-demo
bash: target/xtensa-esp32-espidf/debug/rust-esp32-std-demo: cannot execute binary file: Exec format error

Any ideas?

[Erhannis]

Note: I found this similar sounding issue: rust-lang/cargo#8182
but 1. the error has a ")" instead of "(", which COULD be significant, and 2. cleaning doesn't fix the problem

[MabezDev]

that repo doesn't have a runner set in .cargo/config.toml that's why cargo run is failing. Either set it up like the template or use cargo-espflash. Then it should work :)

[Erhannis]

Ah; sorry, I forgot you needed to run it differently; that ran.
Unfortunately, the problem remains - on
rustc 1.69.0-nightly (e7a0991 2023-04-17) (1.69.0.0)
the code deadlocks with a cap of 0, works with a cap of 1, but when compiled for my laptop (by copying the relevant code into a test project) it works fine with either of the caps.