| 3 Oct 2022 |
 thebutlah | What is strange is that if I remove the breakpoint, and click play, only then does the breakpoint on my ExceptionHandler trigger | 04:39:19 |
| thebutlah | so my thought is that perhaps there is some stack overflow, or some internal queue of futures, that grows too large and a memory access violation occurs, which is what the exception handler catches | 04:39:56 |
| thebutlah | * so my thought is that perhaps there is some stack overflow, or some internal queue of futures, that grows too large and a memory access violation occurs, which is what the exception handler catches. | 04:40:16 |
 9names | if you suspect stack overflow you should check your stack pointer address vs top-of-stack address to see how large the stack has grown | 04:45:01 |
| thebutlah | * What is strange is that if I remove the breakpoint, and click play, only then does the breakpoint on my ExceptionHandler trigger, with an invalid opcode exception (technically Illegal Instruction exception) | 04:49:48 |
| thebutlah | * What is strange is that if I remove the breakpoint, and click play, only then does the breakpoint on my ExceptionHandler trigger, with an invalid opcode exception (technically Illegal Instruction exception) which may be a stack guard or something that rustc put in | 04:50:04 |
| thebutlah | in order to do that I would need to break on whatever is getting run when the .await is called | 04:50:59 |
| thebutlah | I think | 04:51:01 |
| thebutlah | so that would be something inside embassy, but I don't know enough about async executors to know what | 04:51:23 |
| 9names | you should be able to claw that sort of info (program counter, return address, stack pointer) out of the trapframe in the exception handler | 04:56:55 |
| thebutlah | I printed the trap frame contents, I'm just unfamiliar with RISC-V registers to know what in here is helpful info, and how to interpret it | 05:17:20 |
| thebutlah | I have made a minimally reproducible example that only uses embassy. The IllegalInstruction exception still occurs, but only on --release. | 05:23:22 |
| 9names | the frame you printed doesn't contain SP, but if i read the asm for default_start_trap in riscv-rt correctly it only walks the pointer back far enough to store the register values, so you should be able to break on your exception handler and check it.
stack pointer is register x2.
what code is at the return address (ra) in that stack frame? | 05:28:04 |
| thebutlah | to to make sure I understand, you want me to set a breakpoint on what line, and check what registers? | 05:37:58 |
| thebutlah | https://github.com/SlimeVR/SlimeVR-Rust/blob/a6cbbd070c088f4d2c8171475145f07af9a6590d/firmware/src/main.rs | 05:38:10 |
| thebutlah | I have opened an issue in embassy: https://github.com/embassy-rs/embassy/issues/995 | 05:39:29 |
| thebutlah | * https://github.com/SlimeVR/SlimeVR-Rust/blob/b78a684c2def7213b922bbc0a7d2ef287c9dd0e5/firmware/src/main.rs | 05:45:24 |
| thebutlah | In reply to @9names:matrix.org
the frame you printed doesn't contain SP, but if i read the asm for default_start_trap in riscv-rt correctly it only walks the pointer back far enough to store the register values, so you should be able to break on your exception handler and check it.
stack pointer is register x2.
what code is at the return address (ra) in that stack frame? wasn't sure how to do this, so here are some screenshots of the values when I click on different functions in the stack trace | 06:00:24 |
| thebutlah | 
Download image.png | 06:00:27 |
| thebutlah | 
Download image.png | 06:00:38 |
| thebutlah | mfw I just spent the last 10 hours investigating this and I'm no closer to an answer and doubting my sanity: ☠️ | 08:38:16 |
| 9names | if you check the linker script for esp32c3, you'll see that the top of DRAM is 0x3fce0000. and your stack pointer at the point of exception is at 0x3fccf710, which is 67824 bytes below.
so unless you've got 325392 bytes of static memory tied up in static variables you've still got plenty of room for the stack to grow.
that means that stack overflow is not the most likely cause of your problems, and you can start working on checking your other, more likely hypotheses. | 10:04:44 |
|  Limeth joined the room. | 11:34:47 |
 lulf | dirbaio: is something wrong with the embassy website? It seems like it gets redirected to the book. | 16:17:32 |
 dirbaio | yeah, something is wrong yep | 16:17:47 |
| lulf | I wonder if the gha copy is including some toplevel index.html that overwrites the 'root' one | 16:20:44 |
| thebutlah | In reply to @9names:matrix.org
if you check the linker script for esp32c3, you'll see that the top of DRAM is 0x3fce0000. and your stack pointer at the point of exception is at 0x3fccf710, which is 67824 bytes below.
so unless you've got 325392 bytes of static memory tied up in static variables you've still got plenty of room for the stack to grow.
that means that stack overflow is not the most likely cause of your problems, and you can start working on checking your other, more likely hypotheses. the thing is that the the mepc register gives me 0x4144C888, but IROM goes from 0x4200 0000 to 0x4240 0000. So doesn't that mepc mean that we tried to execute an instruction outside of IROM? | 17:54:55 |
| thebutlah | https://five-embeddev.com/riscv-isa-manual/latest/machine.html#machine-exception-program-counter-mepc | 17:56:00 |
| dirbaio | thebutlah: have you tried with target riscv32imc-unknown-none-elf? | 19:06:34 |
| dirbaio | esp32c3 is riscv32imc, not riscv32imac | 19:06:39 |
