Closed jjh84 closed 2 years ago
Confirmed.
I just take a look at the git commits of fswatch. From version 1.11 to 1.16, the major api version of it is still -- 11.
But 1.17 changed the major api verstion to 12 and 1.17.1 changed it to 13. So they broke api backward compatibility twice in a very short period.
In general, that means we should release two new ocaml-fswatch version to match the major api versions respectivelly. But api version 12 looks like an abandoned mistake. To release ocaml-fswatch 13-0.1.0 only is a better idea.
But 1.17 changed the major api verstion to 12 and 1.17.1 changed it to 13. So they broke api back compatibility twice in a very short period.
I checked the source code of fswatch again and found that all the changes occurred in its c++ core. The exported c interface is not changed, so api compatibility wasn't broken. In theory, the 11-0.1.0 bindings are compatible with the new versions of fswatch.
I installed fswatch 1.17.1 and build the 11-0.1.0 bindings with it, and on my linux system, it still works and there is only one thread running.
I noticed that this segmentation fault happened in thread #2 on your setup. ocaml runtime doesn't work well with external c stub thread unless all the extra threads are registered to its runtime system.
It seems that there is thread creation, cevent_callback invocation in your setup which may violate the ocaml runtime rules according to the backtrace.
would you mind taking a try.
change the function
void cevent_callback(fsw_cevent const * const cevents, const unsigned int cevent_num, void *cdata)
in stub.c to
void cevent_callback(fsw_cevent const * const cevents, const unsigned int cevent_num, void *cdata) {
caml_c_thread_register();
CAMLparam0();
CAMLlocal2(session, events);
caml_acquire_runtime_system();
session= caml_copy_nativeint((intnat)cdata);
events= caml_alloc(cevent_num, 0);
for (int i = 0; i < cevent_num; ++i) {
Store_field(events, i, of_fsw_cevent(cevents + i));
}
caml_callback2(*caml_named_value("callback"), session, events);
caml_release_runtime_system();
caml_c_thread_unregister();
CAMLreturn0;
}
at the root path of the project, press
make install
this will install ocaml-fswatch to your current local opam switch. Then build and run the sample program again, see if it'll work or if the backtrace changes?
Thank you. After changing the code, the problem was resolved. It works as expected.
$ fs
events:
/private/tmp/e 8:4:32
You mentioned that Linux has only 1 thread but 2 on macOS. Is it okay If I apply this patch on Linux OS?
Within ocaml runtime system, it's safe to register a known thread(main thread, registered thread, threads created by Thread.create) and unregister an unknown thread(external thread, already unregistered thred). So it's okay to apply this patch to any system.
Do you have a plan to release the patch via opam?
I'll make a PR before tomorrow. So, wait for a while and the new release comes.
fixed in 1898d9c
opam repo progress https://github.com/ocaml/opam-repository/pull/21796
Hello.
Recently, fswatch has been updated to
v1.17.1
and it seems that it break ocaml-fswatch's c stub. When I compile and run the following OCaml code that you have provided viaREADME.md
, I receivedsegmentation fault
error.The executiion result.
The lldb result
Test environment
homebrew
opam