Skip to content

Infinite loop #319

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

Closed
Polygons1 opened this issue Dec 25, 2024 · 4 comments
Closed

Infinite loop #319

Polygons1 opened this issue Dec 25, 2024 · 4 comments

Comments

@Polygons1
Copy link

Polygons1 commented Dec 25, 2024

There is an infinite loop that was introduced in #214 that breaks https://github.com/Snowiiii/Pumpkin from stopping

@xacrimon
Copy link
Owner

xacrimon commented Feb 1, 2025

Hi! I'm looking into this now (since infinite loop bugs are a severe issue to fix ASAP) and since you're pointing at the lock implementation, that leads me to wonder where the issue is. It could be one of either

  • an issue in dashmap, where it's using the locks internally incorrectly and deadlocking when it shouldn't
  • pumpkin is using dashmap incorrectly, violating the rule that a single thread cannot violate the XOR rule by for example
    trying to acquire two mutable references to values at keys A and B and keeping them alive at the same time.

Can you point to where in pumpkins code this infinite loop is occurring and provide reproduction steps?

@Polygons1
Copy link
Author

Thanks for your response!

I believe the issue occurs in either lock_exclusive_slow or lock_shared_slow (if I recall correctly).

The breaking call seems to be DashMap::get.

@xacrimon
Copy link
Owner

xacrimon commented Feb 1, 2025

No, that isn't the info I needed. Of course the top of the callstack and this infinite loop (as is any deadlock, look up the term) is going to be inside dashmap. Structures that use locks and expose references to the caller, like dashmap or any code using Mutex from std is going to be carefully written to protect against deadlocks, you cannot protect against those; that is up to the user to follow some set of guidelines provided to avoid falling into a deadlock condition.

You would get similar issues if you tried to lock a Mutex or Rwlock as write twice at the same time and it isn't the locks that are at fault. To know if it's actually a bug in dashmap and not incorrect usage of it, (documentation states a thread at once instant cannot perform a write action while holding a read reference to the map for example. the rules are the same as they are for rwlock in rust std) I would need some minimal example code that causes this bug or pointed out where it's happening in pumpkin, where it's calling dashmap and it never returns. Otherwise I can't really tell.

@xacrimon
Copy link
Owner

xacrimon commented Feb 1, 2025

Though I did just go and skim all references to dashmap inside the linked repository using code search since I had some time over and I am pretty confident this is not a dashmap bug, pumpkin is just violating the access restrictions causing a deadlock.

Due to that, closing this as not a bug unless meaningful evidence pointing out what exactly is happening in what context emerges.

@xacrimon xacrimon closed this as completed Feb 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants