Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assertion failed: !self.0.access(cs).freeq.is_empty() in rtic-sync 1.0.1 when trying to send data to channel #780

Open
pistolero opened this issue Jul 24, 2023 · 5 comments
Labels
Unconfirmed Currently unable to reproduce

Comments

@pistolero
Copy link

panicked at 'assertion failed: !self.0.access(cs).freeq.is_empty()', /home/serg/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rtic-sync-1.0.1/src/channel.rs:301:17

I've tried checking the code myself, but it is not trivial, so any help would be appreciated

@korken89
Copy link
Collaborator

Hi, thanks for the report!

Do you have an example we can use to reproduce this?
I checked tests and this assert is quite well tested so I'm not sure what's wrong, any help to narrow it down would be appreciated!

@pistolero
Copy link
Author

I was hitting it consistently for some time and now it's gone.

I'll try to find a case where it is reproducing consistently and show you how to reproduce it. I think it was related to publishing messages before reader started to read them.

@korken89
Copy link
Collaborator

Thanks, I hope you can trigger it again!

@korken89
Copy link
Collaborator

korken89 commented Aug 5, 2023

Hi @pistolero I just wanted to check-in if you ran into this again?

I have a theory on what can happen, and would like to check if this is similar to what you did.
If you at a higher priority use try_send and at the same time use send at a lower priority I think the free queue can become inconsistent if hit just right.
I've not been able to reproduce it in tests though...

Were you doing something similar to this? I've tested extensively with different dropping/forgetting of the receiver and were unfortunately not able to reproduce :(

@pistolero
Copy link
Author

Not yet, had no chance to get back to this 😓

I think it was happening when queue was full, I had a software thread which was posting data to queue periodically and this assertion was failing when receiver of the queue were blocked (there were no Ethernet connection).

@AfoHT AfoHT added the Unconfirmed Currently unable to reproduce label Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unconfirmed Currently unable to reproduce
Projects
None yet
Development

No branches or pull requests

3 participants