Crate panics

[dscso]

When running this crate on a STM32F767ZI (nucleo-dev board) I once got the following panic after I disconnected the ethernet cable:

1970-01-01T00:00:57.670Z ERROR panicked at /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/stm32-eth-0.8.0/src/dma/smoltcp_phy.rs:90:56:
called `Option::unwrap()` on a `None` value
└─ main::panic_probe::panic @ src/panic_probe.rs:17   

stm32-eth/src/dma/smoltcp_phy.rs

Line 90 in f9811ec

let packet = self.rx_ring.recv_next(meta).ok().unwrap();

I am using this crate v0.8.0 with the PTP feature enabled. I can't reproduce the error, just wanted to mention it, if this helps. Feel free to close the issue if you don't have the capacity to look into it.

Thank you very much for this great crate, without it my project would not be possible!

[datdenkikniet]

Hmm... That really shouldn't happen. The comment on the line above is correct and should indeed prevent this unwrap from ever panicking.

Do you have any reference code for your project that I can look at to see if there is anything obviously different, and/or are you calling recv_next manually someplace else, somehow?

[dscso]

Thank you very much for your help!

I was using some code pretty close to this one...

Do you have any reference code for your project that I can look at to see if there is anything obviously different, and/or are you calling recv_next manually someplace else, somehow?

I think you can't actually call this code since it is not marked as public right?

But I could not reproduce the bug. So this might have been a bug somewhere else. If you say it should really not happen, I will just trust your judgement and we can close this issue. I will reopen it, it the bug appears again :).

[dscso]

My suspicion is that I actually had a stack overflow. Unfortunately on embedded devices using RTIC there is no real protection against this, so the stack grows into the .bss and .data section without warning.

I have deliberately tried to cause a stack overflow, and then this happend:

panicked at /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/stm32-eth-0.8.0/src/dma/tx/mod.rs:83:9:
index out of bounds: the len is 1443079166 but the index is 4279959972 (main src/panic_probe.rs:17)

I have added flip link into my build chain, which is a tool that crashes the CPU on stack overflow. If the error happens again anyways, I will reopen the issue.

I am sorry for wasting your time, at the end it seems to be an error in my code :)

[dscso]

Actually I had the same error even with flip-link so it does not seem to be a stack overflow

#101

[Lishen1]

Why just not let handle recv_next by smoltcp?

[datdenkikniet]

Alright, I will need your help to debug/reproduce this:

The current token implementations mutably borrow the underlying RxRing and TxRing, (and by extension the EthernetDMA itself), so it is impossible for any recv_next() or send_next() to be called in between creation of and "redemption" of the tokens.

This means that, one way or another:

1. An RxToken is created for the current index, which is available
2. While the RxToken is alive (and mutably borrows the responsible RxRing, which is the only way to gain access to the underlying data buffer and change the availability status), the availability status of the current index changes
3. The token is consumed, and the crate panics

The way I see it, there are three different possible causes:

1. The library has UB. This is not impossible, as interacting with the descriptors is difficult. Perhaps some detail in the Descriptor implementation is unsound.
2. There is some UB in the crates that you and the other affected user are using (unlikely, but who knows).
3. The chip both of you are using does something unexpected, and is indeed flipping the availability status.

For both @dscso and @Lishen1, I'd like to know the following:

1. What chip are you running this on?
2. How often do you see this behaviour?
3. Do you have source code available for the application that's exhibiting this behaviour?
4. In what circumstances does this happen? During normal running? Only if you unplug the cable while the device is receiving? Only when the cable is unplugged? Etc. etc.

Why just not let handle recv_next by smoltcp?

I don't understand what you mean by this, please elaborate.

[Lishen1]

1. using stm32f767
2. just once. I saw other panics but with exact location only one (debugger was connected)
3. mostly code based on https://github.com/pendulum-project/statime stm32 example. Full code on private repository on require some local crates (public forks with some patches) if you need i can provide access and assist to build

[Lishen1]

I think problem related with "loading". I never saw this problem on test environment. But on environment with lan activity ( more some multicast traffic) problem occured

[datdenkikniet]

Hm, I think I've red-herringed myself: I was convinced the problem was a WouldBlock, but that is not the only error that can occur. However, we never actually deal with non-WouldBlock errors.

I think that is the first avenue I will explore, and the first issue I will most definitely fix.