Skip to content

open-rmf/rmf_site freezes when updating from 1.5.1 to 1.5.3 #57

New issue

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

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

Already on GitHub? # to your account

Closed
taiki-e opened this issue Oct 10, 2023 · 4 comments · Fixed by #61
Closed

open-rmf/rmf_site freezes when updating from 1.5.1 to 1.5.3 #57

taiki-e opened this issue Oct 10, 2023 · 4 comments · Fixed by #61

Comments

@taiki-e
Copy link
Collaborator

taiki-e commented Oct 10, 2023

Hello! I'm not sure whether it's a stack overflow but indeed our app was also broken when updating from 1.5.1 to 1.5.3. It's a complex app based on the Bevy game engine, where running it normally freezes, running it after locking the async-executor through cargo update -p async-executor --precise 1.5.1 works well.
It's a bit hard to understand what is happening and I don't want to bring in any red herring but bevy uses this executor to handle its tasks and it seems to get stuck in a sort of endless busy loop, without any significant memory leak but without any progress on the tasks it has assigned.

The app is here but I wouldn't really ask to run it and troubleshoot. Just thought I'd report the issue since we encountered it in a quite different package from the OP, so maybe it can shed some light.

Originally posted by @luca-della-vedova in #53 (comment)

@hymm
Copy link

hymm commented Oct 10, 2023

Some bevy users have reported hanging here also. bevyengine/bevy#10032.

It's probably related to running nested executors, but I haven't have time to dig into it yet.

@notgull
Copy link
Member

notgull commented Oct 10, 2023

There is a busy loop mentioned; if you use a debugger to stop in the middle of this loop, what backtrack do you see? This would help us identify what part of the program is stuck in a loop.

@hymm
Copy link

hymm commented Oct 10, 2023

There's a backtrace in the issue I linked above.

@notgull
Copy link
Member

notgull commented Oct 11, 2023

Nested executors have been a rough sticking point for a while now. I'd like to implement some code to simplify it so that nested executors aren't as much of a problem. The best solution would be to use the thread-local crate to reduce the number of workarounds we need, but I'm not sure that that crate's MSRV fits our policy. See Amanieu/thread_local-rs#62

notgull added a commit that referenced this issue Oct 17, 2023
This was added in #37 as an optimization, but has since lead to many bugs. See
the issues #53, #57 and #60 for more information. I do not have the bandwidth
to address all of these bugs, so I'm taking the path of least resistance by
just removing the problematic code.

CLoses #53, #57 and #60

Signed-off-by: John Nunley <dev@notgull.net>
notgull added a commit that referenced this issue Oct 17, 2023
This was added in #37 as an optimization, but has since lead to many bugs. See
the issues #53, #57 and #60 for more information. I do not have the bandwidth
to address all of these bugs, so I'm taking the path of least resistance by
just removing the problematic code.

CLoses #53, #57 and #60

Signed-off-by: John Nunley <dev@notgull.net>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants