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

Infinite loop (and memory usage) #1815

Open
jneem opened this issue Feb 9, 2024 · 4 comments
Open

Infinite loop (and memory usage) #1815

jneem opened this issue Feb 9, 2024 · 4 comments

Comments

@jneem
Copy link
Member

jneem commented Feb 9, 2024

When trying to export the following file, nickel gets stuck and starts using up all my memory:

{ y = { foo = y } }
@jneem jneem added the type: bug label Feb 9, 2024
@yannham
Copy link
Member

yannham commented Feb 14, 2024

I mean, it is an infinite loop, right? Although we should probably be able to detect that without black-holing, and I'm not sure why we don't.

What behavior do you think would be right?

@jneem
Copy link
Member Author

jneem commented Feb 14, 2024

I'd expect the same infinite recursion error that you get from, say let rec y = y in y

@yannham
Copy link
Member

yannham commented Feb 16, 2024

I haven't tested this hypothesis, but I believe it's to be expected that black-holing doesn't detect such loops. In fact, as long as you don't use deep_seq (but both nickel eval and nickel export do use it, which is why it's looping), this term doesn't loop, in that it's always productive: if we evaluate y, we get a lazy record {foo = y}. If we then evaluate foo, we get in one step the record {foo = y}, and so on. It's basically an infinite record { y = { foo = {foo = { foo = ...., which is - at each step - at most one variable substitution away from being in weak head normal form.

So, evaluating y always terminates, and doesn't trigger the infinite recursion detection.

However, this is different when forcing/deep_sequing the record, of course, because we are now trying to recurse into an infinite data structure. I wonder if we can extend the blackholing mechanism to handle this case, by forbidding thunks to be evaluated again while we're still forcing the children of this thunk.

@D-Brox
Copy link

D-Brox commented Mar 19, 2024

Related to #1722

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants