Fatal error: debugger does not support channel locks #10517

anentropic · 2021-07-15T20:26:35Z

I originally posted this on Stackoverflow, thinking it a problem with my code or some library incompatibility.
https://stackoverflow.com/questions/68394075/fatal-error-debugger-does-not-support-channel-locks

I had a reply there suggesting it was likely an issue with ocamldebug and macos and I should report it here, so I'll reproduce details below.

Firstly I am on macOS Catalina (10.15.7) on an Intel cpu.

I initially set up my project by:

brew install ocaml opam
opam switch create . ocaml-base-compiler.4.12.0
eval $(opam env)

I have added (modes byte exe) to my dune file.

When I run dune build I can see the bytecode file output, alongside the exe, as _build/default/bin/cli.bc

When I pass this to ocamldebug I get the following error:

ocamldebug _build/default/bin/cli.bc
	OCaml Debugger version 4.12.0

(ocd) r
Loading program... done.
Fatal error: debugger does not support channel locks
Lost connection with process 33035 (active process)
between time 170000 and time 180000
Restart from time 170000 and try to get closer of the problem ? (y or n)

If I choose y the console seems to hang indefinitely.

I found the source of the error here:

ocaml/runtime/debugger.c

Line 144 in f68acd1

caml_fatal_error("debugger does not support channel locks");

  /* The code in this file does not bracket channel I/O operations with
     Lock and Unlock, so fail if those are not no-ops. */
  if (caml_channel_mutex_lock != NULL ||
      caml_channel_mutex_unlock != NULL ||
      caml_channel_mutex_unlock_exn != NULL)
    caml_fatal_error("debugger does not support channel locks");

...but I don't know what might be triggering it.

My project is using cmdliner and lwt ...I thought "channel I/O operations" might have something to do with either of those libraries.

But the replier on SO seemed to think it was more likely an OS-level issue with my install of ocamldebug itself.

The text was updated successfully, but these errors were encountered:

nojb · 2021-07-15T20:32:55Z

I believe the message debugger does not support channel locks refers to the fact that the debugger does not support programs that enable multi threading via the threads library. Perhaps lwt does this indirectly?

dra27 · 2021-07-16T07:20:17Z

Does your project use lwt.unix?

anentropic · 2021-07-16T08:35:58Z

@dra27 I think so, yes... indirectly via https://github.com/mirage/irmin/

xavierleroy · 2021-07-19T07:29:11Z

We should have a better error message! But, yes, ocamldebug doesn't work with multithreaded programs.

anentropic · 2021-07-19T08:09:36Z

ok thanks, good to know

looks like I need to temporarily vendor irmin into my project and put in some print debugging then

dra27 · 2021-07-19T08:57:02Z

If you are certain (and I mean really, really certain) that no threads are ever created, for debugging purposes only, you could recompile systhreads.cma with:

ocaml/otherlibs/systhreads/thread.ml

Line 69 in f203a5d

thread_initialize ();

commented out or, possibly less unsafely, these 3 lines commented out:

ocaml/otherlibs/systhreads/st_stubs.c

Lines 469 to 471 in f203a5d

    
           caml_channel_mutex_lock = caml_io_mutex_lock; 
        
           caml_channel_mutex_unlock = caml_io_mutex_unlock; 
        
           caml_channel_mutex_unlock_exn = caml_io_mutex_unlock_exn;

commented out. But you must be absolutely certain that no threads will be created.

anentropic · 2021-07-19T09:03:51Z

seems pretty clear that lwt uses threads https://github.com/ocsigen/lwt/search?q=threads so I guess i'm out of luck

xavierleroy · 2021-07-21T07:21:17Z

It would be nice if we could start ocamldebug on a program that was linked with the threads library and fail only when the first thread is actually created.

anentropic · 2021-07-21T07:34:24Z

Out of curiosity, is this situation going to get better or worse with multi-core OCaml?

…t threads ocamldebug has never worked with multithreaded programs: multiple threads mess up the communication protocol with the debugger, and the fork()-based checkpointing mechanism breaks too. Up to 4.11, the debugger would work fine until the first thread was created. Then, bizarre errors would be reported. In 4.12 (commit e678885), a check was added, causing any program linked with the threads library to report a fatal error at start-up time when run under the debugger. As reported in ocaml#10517, this check is too strong: some programs just happen to be linked with the threads library, e.g. because they use LWT, but may never start a thread. There's no reason to refuse to debug these programs. This commit reverts the 4.12 change and adds a check in Thread.create that aborts the program if it is run under the debugger. This way, programs linked with the threads library can still be debugged until the point where they create new threads.

xavierleroy · 2021-08-31T14:58:01Z

It would be nice if we could start ocamldebug on a program that was linked with the threads library and fail only when the first thread is actually created.

See #10594

xavierleroy · 2021-08-31T15:00:24Z

Out of curiosity, is this situation going to get better or worse with multi-core OCaml?

As far as I know, no better and no worse, i.e. the debugger should remain compatible with single-domain, single-thread programs only.

…t threads ocamldebug has never worked with multithreaded programs: multiple threads mess up the communication protocol with the debugger, and the fork()-based checkpointing mechanism breaks too. Up to 4.11, the debugger would work fine until the first thread was created. Then, bizarre errors would be reported. In 4.12 (commit e678885), a check was added, causing any program linked with the threads library to report a fatal error at start-up time when run under the debugger. As reported in #10517, this check is too strong: some programs just happen to be linked with the threads library, e.g. because they use LWT, but may never start a thread. There's no reason to refuse to debug these programs. This commit reverts the 4.12 change and adds a check in Thread.create that aborts the program if it is run under the debugger. This way, programs linked with the threads library can still be debugged until the point where they create new threads.

…10594) ocamldebug has never worked with multithreaded programs: multiple threads mess up the communication protocol with the debugger, and the fork()-based checkpointing mechanism breaks too. Up to 4.11, the debugger would work fine until the first thread was created. Then, bizarre errors would be reported. In 4.12 (commit e678885), a check was added, causing any program linked with the threads library to report a fatal error at start-up time when run under the debugger. As reported in #10517, this check is too strong: some programs just happen to be linked with the threads library, e.g. because they use LWT, but may never start a thread. There's no reason to refuse to debug these programs. This commit reverts the 4.12 change and adds a check in Thread.create that aborts the program if it is run under the debugger. This way, programs linked with the threads library can still be debugged until the point where they create new threads.

xavierleroy · 2021-09-01T07:45:26Z

#10594 is merged and adds a clearer error message + the ability to debug the program until it calls Thread.create. I think this is the best we can do without an extensive rewrite of ocamldebug. Hence I'll close this report.

nikswamy · 2022-03-09T21:20:40Z

I'm using OCaml 4.12. My program does have some uses of Thread.create/join, and Mutex.lock/unlock.

When running my program using ocamldebug on Linux, it fails very quickly with Fatal error: debugger does not support channel locks.

However, running the same program on Windows/Cygwin does not exhibit this error and ocamldebug goes much further, until it eventually dies with Fatal error: exception Sys_error("An existing connection was forcibly closed by the remote host.\r\n")

Is there a reason for this difference in behavior? Thanks in advance!

xavierleroy · 2022-03-10T18:58:59Z

The Windows/Cygwin behavior you describe is consistent with OCaml 4.11 or earlier. The "debugger does not support channel lock" error was introduced in 4.12 but should show up with Cygwin as well as with other systems.

The soon-to-be-released OCaml 4.14.0 should restore a 4.11-like behavior, namely: you can debug up to the point where the program creates its first thread.

xavierleroy mentioned this issue Aug 31, 2021

Support debugging multithreaded programs until they create threads #10594

Merged

xavierleroy closed this as completed Sep 1, 2021

SkySkimmer mentioned this issue Oct 20, 2021

[ocaml] Version bump for 8.16 ? coq/coq#14260

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fatal error: debugger does not support channel locks #10517

Fatal error: debugger does not support channel locks #10517

anentropic commented Jul 15, 2021

nojb commented Jul 15, 2021

dra27 commented Jul 16, 2021

anentropic commented Jul 16, 2021 •

edited

xavierleroy commented Jul 19, 2021

anentropic commented Jul 19, 2021

dra27 commented Jul 19, 2021

anentropic commented Jul 19, 2021

xavierleroy commented Jul 21, 2021

anentropic commented Jul 21, 2021

xavierleroy commented Aug 31, 2021

xavierleroy commented Aug 31, 2021

xavierleroy commented Sep 1, 2021

nikswamy commented Mar 9, 2022

xavierleroy commented Mar 10, 2022

Fatal error: debugger does not support channel locks #10517

Fatal error: debugger does not support channel locks #10517

Comments

anentropic commented Jul 15, 2021

nojb commented Jul 15, 2021

dra27 commented Jul 16, 2021

anentropic commented Jul 16, 2021 • edited

xavierleroy commented Jul 19, 2021

anentropic commented Jul 19, 2021

dra27 commented Jul 19, 2021

anentropic commented Jul 19, 2021

xavierleroy commented Jul 21, 2021

anentropic commented Jul 21, 2021

xavierleroy commented Aug 31, 2021

xavierleroy commented Aug 31, 2021

xavierleroy commented Sep 1, 2021

nikswamy commented Mar 9, 2022

xavierleroy commented Mar 10, 2022

anentropic commented Jul 16, 2021 •

edited