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

"thread blocked indefinitely in an MVar operation" errors #1014

Closed
dbp opened this issue Jan 1, 2024 · 6 comments
Closed

"thread blocked indefinitely in an MVar operation" errors #1014

dbp opened this issue Jan 1, 2024 · 6 comments
Labels

Comments

@dbp
Copy link

dbp commented Jan 1, 2024

I assume this is a regression from #844.

I have an old site that I haven't changed for years and years. I recently, due to CI updates, had to update it to current Hakyll/GHC 9.4, getting this new runtime.

Despite runing with only one thread ("Using async runtime with 1 threads..."), it seems like the order that pages are generated has changed. This is causing intermittent errors (presumably there are dependencies that were implicit, which previously was fine, since the order pages were created used to correspond to the order in file, and now presumably is due to the graph sorting for new runtime). Both calls to error (which are now happening because pages are not generated in the right order) and, it seems, some other causes I don't understand, can cause these MVar locking errors.

Running again on the same site (which thus partly generated) will succeed, or maybe after several blocked runs will succeed. This doesn't really work for CI (and is pretty sloppy regardless).

Is there a way to run without this new async runtime (which from the PR, looks like it got pretty minimal testing before merging...)? There is a reason why this site of mine hasn't been changed in years; I really don't have the time/budget to significantly debug/rewrite it.

@jaspervdj
Copy link
Owner

Is there any chance the site is open source so we could reproduce this?

Most dependencies should be tracked implicitly already in Hakyll, so I think it’s more likely that rules could be overwriting each other like in #1000 (even though a check was added for that).

@dbp
Copy link
Author

dbp commented Jan 4, 2024

It's probably fine for it to be public -- https://github.com/dbp/lydiajohnston -- I don't think the same file is written multiple times, but it does some dynamic stuff, as there is a .yml file that controls metadata for the whole site...

@jaspervdj
Copy link
Owner

Thanks! I was able to reproduce the bug now.

@jaspervdj
Copy link
Owner

I couldn't find anything wrong with the dependencies in that site. Chasing down the error message that appeared in the log, Missing Sea Glass, I found I could fix the build with:

diff --git a/pages/1.yml b/pages/1.yml
index f2ff7f6..4a6823e 100644
--- a/pages/1.yml
+++ b/pages/1.yml
@@ -1,7 +1,7 @@
 paintings:
 - id: Arise
   price: $1450, Oil/Cold Wax on Panel, Framed
-- id: Sea Glass
+- id: Sea_Glass
   price: $1450, Oil/Cold Wax on Panel, Framed

 - id: Trading_Whisper

I suspect this was also an error in the old runtime, which (wrongly) ignored it.

It's still a bit of a problem that calling error can cause a thread blocked indefinitely in an MVar operation issue, that is very misleading and needs to be fixed.

@dbp
Copy link
Author

dbp commented Jan 5, 2024

What's interesting (you're right, of course) is that with the new runtime, running it multiple times seems to get past the error, which is strange. Maybe it partly creates the file, and then as a result doesn't re-run the (failing) job? I guess that might have been the case in the past too (I'm not sure if I would have re-run something given the error).

jaspervdj added a commit that referenced this issue Jan 6, 2024
Various things may go wrong when a user-provided `Compiler` is producing an
`Item`.  Typically these end up as a `CompilerError` which gets logged and
we stop execution.

However, due to laziness, it's possible to have a compiler succeed, but return
an `Item` that will throw an exception when it's written.  This will break the
waiting mechanism in the scheduler, causing a `thread blocked indefinitely in an
MVar operation` error like in #1014.  I added a test case reproducing this.
jaspervdj added a commit that referenced this issue Jan 8, 2024
Various things may go wrong when a user-provided `Compiler` is producing an
`Item`.  Typically these end up as a `CompilerError` which gets logged and
we stop execution.

However, due to laziness, it's possible to have a compiler succeed, but return
an `Item` that will throw an exception when it's written.  This will break the
waiting mechanism in the scheduler, causing a `thread blocked indefinitely in an
MVar operation` error like in #1014.  I added a test case reproducing this.
@jaspervdj
Copy link
Owner

I'm going to close this, as #1015 will stop execution and make it more obvious when an error is encountered, so it should prevent similar issues going forward.

@Minoru Minoru added the bug label Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants