Crashes on FreeBSD with "Mutex.lock: Resource deadlock avoided"

[ALPHA-60]

When compiled on FreeBSD 12.1 with ocamlc 4.09.1 from opam, running lsp server results in:

ocamllsp: internal error, uncaught exception:
          Sys_error("Mutex.lock: Resource deadlock avoided")
          Raised by primitive operation at file "lsp/src/scheduler.ml", line 108, characters 4-22
          Called from file "lsp/src/scheduler.ml", line 272, characters 4-22
          Called from file "lsp/src/rpc.ml", line 17, characters 14-39
          Called from file "ocaml-lsp-server/src/ocaml_lsp_server.ml", line 750, characters 4-39
          Called from file "lsp/src/logger.ml", line 155, characters 8-12
          Re-raised at file "lsp/src/logger.ml", line 161, characters 4-19
          Called from file "vendor/cmdliner/src/cmdliner_term.ml", line 25, characters 19-24
          Called from file "vendor/cmdliner/src/cmdliner.ml", line 117, characters 32-39

In general

let t = Mutex.create() in
Mutex.lock t;
Mutex.lock t

on FreeBSD results in Fatal error: exception Sys_error("Mutex.lock: Resource deadlock avoided"), but on Linux it blocks, so I'm not sure if this is something specific to ocaml-lsp, or to ocamlc on FreeBSD.

Reverting to parent of 51f0de6 ("scheduler tweaks") makes this error go away.

[rgrinberg]

@ulugbekna Mind taking a look? Otherwise we'll just need to revert. Unfortunately, I don't very much about BSD, but would definitely prefer if things worked there.

[ulugbekna]

I remember we previously discussed this piece of code. I will look into this during the weekend but can't promise I'll be able to solve this. I know little about threads module and BSD.

In my opinion, locking a mutex twice should result in a deadlock; maybe since the second lock is done by the same thread, it is a no-op and just gives some time for the thread to be created (to avoid races, as you said in slack DM). Has removing the second lock resulted in bad behavior of the program previously?

[anuragsoni]

FWIW ocaml 4.12 might get errorchecking mutex behavior as default and attempting to lock a mutex from the thread that already owns the mutex will raise a Sys_error exception
https://github.com/ocaml/ocaml/pull/9846/files#diff-0ab05a914abe0b1fe88f203ed7bb9bbdR39

[cdaringe]

seeing this error on HEAD, 59c9138--installed today on 4.10.0+multicore

[rgrinberg]

Could one of you try this on master again? #264 is supposed to fix this I think.

[anuragsoni]

@rgrinberg I tried this on freebsd and #264 indeed fixes the issue reported here.

[ALPHA-60]

I can confirm that the error is gone when running ocamllsp on 8092592 built with 4.10.1.

[rgrinberg]

Thanks everyone