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

Watch mode crashes on macos on main branch #9004

Closed
voodoos opened this issue Oct 26, 2023 · 3 comments · Fixed by #9009
Closed

Watch mode crashes on macos on main branch #9004

voodoos opened this issue Oct 26, 2023 · 3 comments · Fixed by #9009

Comments

@voodoos
Copy link
Collaborator

voodoos commented Oct 26, 2023

On my machine, watch mode is broken on the main branch.
@emillon mentioned it might be linked to #8304

Specifications

  • Version of dune: 3.11.0-221-g5b6c8f4 (main)
  • Version of ocaml: 4.14.1 (and 5.1.0)
  • Operating system (distribution and version): MacOS Sonoma (M1 pro)

Reproduction

  • Clean copy at 5b6c8f4
  • make dev
  • ./dune.exe build @install -w
$ ./dune.exe build @install -w     
Internal error, please report upstream including the contents of _build/log.
Description:
  ("Fsevents.start: dispatch queue stopped", {})
Raised at Stdune__Code_error.raise in file
  "otherlibs/stdune/src/code_error.ml", line 10, characters 30-62
Called from Stdlib__Fun.protect in file "fun.ml", line 33, characters 8-15
Re-raised at Stdlib__Fun.protect in file "fun.ml", line 38, characters 6-52
Called from Stdlib__Fun.protect in file "fun.ml", line 33, characters 8-15
Re-raised at Stdlib__Fun.protect in file "fun.ml", line 38, characters 6-52
Called from Dune_file_watcher.add_watch in file
  "src/dune_file_watcher/dune_file_watcher.ml", line 729, characters 13-50
Called from Dune_engine__Fs_memo.Watcher.watch_path in file
  "src/dune_engine/fs_memo.ml", line 69, characters 10-50
Called from Dune_engine__Fs_memo.Watcher.memo_for_watching_via_parent.(fun)
  in file "src/dune_engine/fs_memo.ml", line 130, characters 8-58
Called from Fiber__Scheduler.exec in file "vendor/fiber/src/scheduler.ml",
  line 76, characters 8-11
-> required by
   ("fs_memo_for_watching_via_parent",
   External "/Library/TeX/texbin/latexmk/hg")
-> required by ("which", <opaque>)
-> required by ("which", <opaque>)
-> required by ("<unnamed>", ())
-> required by ("<unnamed>", ())
-> required by
   ("load-dir", In_build_dir "default/test/blackbox-tests/test-cases/cram")
-> required by ("toplevel", ())

I must not crash.  Uncertainty is the mind-killer. Exceptions are the
little-death that brings total obliteration.  I will fully express my cases. 
Execution will pass over me and through me.  And when it has gone past, I
will unwind the stack along its path.  Where the cases are handled there will
be nothing.  Only I will remain.
@Alizter
Copy link
Collaborator

Alizter commented Oct 26, 2023

cc @kevinji

@kevinji
Copy link
Contributor

kevinji commented Oct 27, 2023

Apologies for the bug, I just submitted #9009 as a fix. Let me know if that fixes the issue for you; I was able to reproduce the issue on main and saw it go away with the changes in this PR.

@voodoos
Copy link
Collaborator Author

voodoos commented Oct 27, 2023

Thanks for the fast reaction, your fix does make the issue disappear :-)

voodoos pushed a commit to voodoos/dune that referenced this issue Nov 21, 2023
Previously, the code waiting on `dq->dq_finished` would get notified in
`dune_fsevents_dispatch_queue_wait_until_stopped` that the dispatch
queue had completed running. This would lead to the dispatch queue being
marked as `Stopped` on the OCaml side, even though the dispatch queue
could be passed into `Fsevents.start` again.

This change now tracks the number of fsevents streams in a
`fsevents_streams` counter so that `Dispatch_queue.wait_until_stopped`
will only return when an exception is raised or if all streams have been
stopped, restoring the original behavior in the code that used a runloop.

Fixes ocaml#9004. Fixes ocaml#8910.

Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
emillon pushed a commit that referenced this issue Nov 28, 2023
Previously, the code waiting on `dq->dq_finished` would get notified in
`dune_fsevents_dispatch_queue_wait_until_stopped` that the dispatch
queue had completed running. This would lead to the dispatch queue being
marked as `Stopped` on the OCaml side, even though the dispatch queue
could be passed into `Fsevents.start` again.

This change now tracks the number of fsevents streams in a
`fsevents_streams` counter so that `Dispatch_queue.wait_until_stopped`
will only return when an exception is raised or if all streams have been
stopped, restoring the original behavior in the code that used a runloop.

Fixes #9004. Fixes #8910.

Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
voodoos pushed a commit to voodoos/dune that referenced this issue Nov 28, 2023
Previously, the code waiting on `dq->dq_finished` would get notified in
`dune_fsevents_dispatch_queue_wait_until_stopped` that the dispatch
queue had completed running. This would lead to the dispatch queue being
marked as `Stopped` on the OCaml side, even though the dispatch queue
could be passed into `Fsevents.start` again.

This change now tracks the number of fsevents streams in a
`fsevents_streams` counter so that `Dispatch_queue.wait_until_stopped`
will only return when an exception is raised or if all streams have been
stopped, restoring the original behavior in the code that used a runloop.

Fixes ocaml#9004. Fixes ocaml#8910.

Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
voodoos pushed a commit to voodoos/dune that referenced this issue Jan 19, 2024
Previously, the code waiting on `dq->dq_finished` would get notified in
`dune_fsevents_dispatch_queue_wait_until_stopped` that the dispatch
queue had completed running. This would lead to the dispatch queue being
marked as `Stopped` on the OCaml side, even though the dispatch queue
could be passed into `Fsevents.start` again.

This change now tracks the number of fsevents streams in a
`fsevents_streams` counter so that `Dispatch_queue.wait_until_stopped`
will only return when an exception is raised or if all streams have been
stopped, restoring the original behavior in the code that used a runloop.

Fixes ocaml#9004. Fixes ocaml#8910.

Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
voodoos pushed a commit to voodoos/dune that referenced this issue Apr 5, 2024
Previously, the code waiting on `dq->dq_finished` would get notified in
`dune_fsevents_dispatch_queue_wait_until_stopped` that the dispatch
queue had completed running. This would lead to the dispatch queue being
marked as `Stopped` on the OCaml side, even though the dispatch queue
could be passed into `Fsevents.start` again.

This change now tracks the number of fsevents streams in a
`fsevents_streams` counter so that `Dispatch_queue.wait_until_stopped`
will only return when an exception is raised or if all streams have been
stopped, restoring the original behavior in the code that used a runloop.

Fixes ocaml#9004. Fixes ocaml#8910.

Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
voodoos pushed a commit to voodoos/dune that referenced this issue Apr 15, 2024
Previously, the code waiting on `dq->dq_finished` would get notified in
`dune_fsevents_dispatch_queue_wait_until_stopped` that the dispatch
queue had completed running. This would lead to the dispatch queue being
marked as `Stopped` on the OCaml side, even though the dispatch queue
could be passed into `Fsevents.start` again.

This change now tracks the number of fsevents streams in a
`fsevents_streams` counter so that `Dispatch_queue.wait_until_stopped`
will only return when an exception is raised or if all streams have been
stopped, restoring the original behavior in the code that used a runloop.

Fixes ocaml#9004. Fixes ocaml#8910.

Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants