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

Paket deadlock since 0.38.0? #746

Closed
matthid opened this issue Apr 2, 2015 · 5 comments
Closed

Paket deadlock since 0.38.0? #746

matthid opened this issue Apr 2, 2015 · 5 comments

Comments

@matthid
Copy link
Member

matthid commented Apr 2, 2015

Paket pretty much always deadlocks since 0.38.
The issue pops up as soon as you delete the cache and are on linux.

Repro:

git clone https://gist.github.com/d8653537d65775db669c.git
mono paket.bootstrapper.exe
rm -r ~/.local/share/NuGet/Cache
mono paket.exe -v restore # deadlock
# if you cancel the above and try again it will work

The last message seems to be different depending on the mono tracing flags. However is seems to be always near the FSharp.Compiler.Service License, after 2 previous 404 warnings.

I tried out the last few versions of Paket until the build started working again, see here: https://travis-ci.org/matthid/Yaaf.Shell/builds. I can repro this on my local gentoo machine as well.
Windows is not hit, as you can see here: https://ci.appveyor.com/project/matthid/yaaf-shell/history

Note it is also possible that the default timeout is >10 minutes (or longer on mono) and that's the reason why travis kills the process (I did not try to wait a day to see if it eventually finishes..)

Or this could be some mono race condition bug we should IMHO work around somehow, if possible.
That said: Can somebody reproduce this? Should I try to send a fix for this?

@forki
Copy link
Member

forki commented Apr 2, 2015

yes please try to send a fix. we should cancel the license download after one or two seconds it's just not important enough.

@forki
Copy link
Member

forki commented Apr 2, 2015

is 6d2f239 ready?

@matthid
Copy link
Member Author

matthid commented Apr 2, 2015

nope still testing

@matthid
Copy link
Member Author

matthid commented Apr 2, 2015

It looks like everything times out now with 5 secs on the async and 3 secs on the request.

@matthid matthid mentioned this issue Apr 2, 2015
@forki forki closed this as completed in 6d2f239 Apr 2, 2015
forki added a commit that referenced this issue Apr 2, 2015
@matthid
Copy link
Member Author

matthid commented Apr 2, 2015

But at least it doesn't fail anymore: See #747.

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