Hang building documentation on racketcs #2725
Comments
|
Unfortunately, I haven't been able to replicate the problem, so far. It makes sense that the main thread would be blocked in |
|
For reference, I had to use Waiting a little while and then breaking again gives similar results. Here's the stack for thread 2: The other similar stacks are very similar, with the same stack frame address in all of them except frame 5. The last thread is different, here's the stack trace: |
|
My only thought at the moment is that it might be an interaction of futures and places. What happens if you comment out the |
|
I commented out that call, got another hang (at a different place in the doc build), and the |
|
That is helpful, and I'm pretty sure we're on the right track. I've pushed a commit that fixes one synchronization problem. I'm not optimistic that I've found the right problem, though. More generally, I'm skeptical that the ad hoc, CAS-based synchronization for custodians and futures is a good idea, and probably there's a better approach. |
|
I started to recently see this on a regular basis. Let me know if I can provide any further information besides what @samth already provided. |
mflatt
added a commit
that referenced
this issue
Jul 18, 2019
|
I was finally able to provoke similar behavior on my machine, and the latest commit fixes several problems. Please let me know whether you see any change. |
|
@mflatt Nope, not recently. I built a 7.4cs from scratch today and didn't face the issue. |
|
I haven't seen this recently either. |
|
This has started happening again. Here's the current best stack information I have: Below is all the threads. |
|
One possibility is that the |
mflatt
added a commit
that referenced
this issue
Oct 9, 2019
Repair problems with asynchronous callbacks for futures and for foreign callbacks. Asynchronous callbacks are used for future "sync" operations, like `hash-set!`, that run must in a place's main thread (as of commit f574583). Separately, synchronization to clean up future threads used a `ping?` flag in a backwards sense, and it also treated a record as a box. These problems could cause place termination to hang. Related to #2725
jbclements
pushed a commit
that referenced
this issue
Oct 10, 2019
Repair problems with asynchronous callbacks for futures and for foreign callbacks. Asynchronous callbacks are used for future "sync" operations, like `hash-set!`, that run must in a place's main thread (as of commit f574583). Separately, synchronization to clean up future threads used a `ping?` flag in a backwards sense, and it also treated a record as a box. These problems could cause place termination to hang. Related to #2725 (cherry picked from commit 7cc3345)
|
This hung again after the most recent changes, here's the backtraces of all threads. |
|
I'm hopeful that this change will actually fix the problem: 61e3965 Broken caching could cause Racket CS to raise an error in atomic mode. If that happens during the doc-build phase, then the place where that error happens would become stuck, and so all of |
|
I haven't seen this in awhile. Can we close? |
MarcKaufmann
pushed a commit
to MarcKaufmann/racket
that referenced
this issue
Apr 15, 2020
MarcKaufmann
pushed a commit
to MarcKaufmann/racket
that referenced
this issue
Apr 15, 2020
Repair problems with asynchronous callbacks for futures and for foreign callbacks. Asynchronous callbacks are used for future "sync" operations, like `hash-set!`, that run must in a place's main thread (as of commit f574583). Separately, synchronization to clean up future threads used a `ping?` flag in a backwards sense, and it also treated a record as a box. These problems could cause place termination to hang. Related to racket#2725
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I consistently get a hang with parallel builds of racketcs on linux. The hang happens here:
and the stack when hanging looks like:
The stack as printed by gdb is pretty useless, but I can disassemble the relevant functions if needed.
The text was updated successfully, but these errors were encountered: