Occasional crashes on OS-X

[lihaoyi]

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000185319554, pid=43806, tid=64775
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.6.10.1 (17.0.6+10) (build 17.0.6+10-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.6.10.1 (17.0.6+10-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# C  [CoreFoundation+0x14f554]  __CFCheckCFInfoPACSignature+0x4

Possibly related to the new native --notify-watch true implementation from os-lib-watch, and seems to come together with errors in the build.mill

[lihaoyi]

Here's the log file

hs_err_pid15791.log

[lihaoyi]

Recently I've noticed sometimes --watch on my laptop just ends, with no error message shown. Not sure if it is a different problem or the same problem with a new manifestation

[alexarchambault]

Recently I've noticed sometimes --watch on my laptop just ends, with no error message shown. Not sure if it is a different problem or the same problem with a new manifestation

Same, this happens pretty often. I'm on macOS too (ARM)

[lihaoyi]

@arturaz is looking into this, but worst case we can revert to polling by default on OSX if we can't figure this out

[arturaz]

I believe it was due to closed not being volatile:
https://github.com/com-lihaoyi/os-lib/blob/638ae3b2c078564d5122aca4b06ed30b03d9f097/os/watch/src/FSEventsWatcher.scala#L14

Then if close() was invoked multiple times, current and dummyCfString was released while pointing to invalid memory because other thread was seeing a stale closed value.

https://github.com/com-lihaoyi/os-lib/blob/638ae3b2c078564d5122aca4b06ed30b03d9f097/os/watch/src/FSEventsWatcher.scala#L100-L109

The new version of os-lib (com-lihaoyi/os-lib#398) should have this fixed.

[lihaoyi]

@arturaz could you explain why .close may be called multiple times? I thought we use Using to manage the lifetime, which should call close only once

[arturaz]

To be honest, I have no idea, but this is the closest to a reasonable explanation I could come up. I think we should try it with the new os-lib and see if it still happens. If it doesn't, great, I see no point in trying to figure out why it happened.