fsevents: fsevent appears to make Electron app crashes

We’ve been having an issue since we’ve upgraded Electron and fsevent (via Chokidar, which is used to watch files and make use of fsevents).

Sometimes the fsevent calls will work but relatively often they will make the NodeJS process used by Electron crash.

It’s not entirely clear how to replicate it but we do have a crash report:

Process:               Electron Helper [46524]
Path:                  /Users/USER/*/Electron.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper
Identifier:            com.github.Electron.helper
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        Electron [46522]
Responsible:           Electron Helper [46524]
User ID:               501

Date/Time:             2019-04-11 20:22:07.263 -0400
OS Version:            Mac OS X 10.14.4 (18E226)
Report Version:        12
Bridge OS Version:     3.4 (16P4507)
Anonymous UUID:        REMOVED

Sleep/Wake UUID:       REMOVED

Time Awake Since Boot: 320000 seconds
Time Since Wake:       1100 seconds

System Integrity Protection: disabled

Crashed Thread:        0  CrRendererMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000000003e8
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [46524]

VM Regions Near 0x3e8:
--> 
    __TEXT                 000000010d44e000-000000010d44f000 [    4K] r-x/rwx SM=COW  /Users/USER/*/Electron.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper

Thread 0 Crashed:: CrRendererMain  Dispatch queue: com.apple.main-thread
0   com.github.Electron.framework 	0x00000001121ea3a0 0x10d451000 + 81367968
1   fse.node                      	0x0000000118800f8b fse::FSEvents::~FSEvents() + 93 (fsevents.cc:65)
2   fse.node                      	0x000000011880101e fse::FSEvents::~FSEvents() + 14 (fsevents.cc:62)
3   com.github.Electron.framework 	0x000000010e831c11 0x10d451000 + 20843537
4   com.github.Electron.framework 	0x000000010e831fca 0x10d451000 + 20844490
5   com.github.Electron.framework 	0x000000010ec922a3 0x10d451000 + 25432739
6   com.github.Electron.framework 	0x000000010ec90341 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) + 1585
7   com.github.Electron.framework 	0x000000010ec992a1 0x10d451000 + 25461409
8   com.github.Electron.framework 	0x000000010e85929f 0x10d451000 + 21004959
9   com.github.Electron.framework 	0x000000010f2031ab 0x10d451000 + 31138219
10  com.github.Electron.framework 	0x000000010f264572 0x10d451000 + 31536498
11  com.github.Electron.framework 	0x000000010f2031ab 0x10d451000 + 31138219
12  com.github.Electron.framework 	0x000000010f21d5ff 0x10d451000 + 31245823
13  com.github.Electron.framework 	0x000000010f21dab8 0x10d451000 + 31247032
14  com.github.Electron.framework 	0x000000010f2c205a 0x10d451000 + 31920218
15  com.github.Electron.framework 	0x000000010f2c531a 0x10d451000 + 31933210
16  com.github.Electron.framework 	0x000000010f2c197f 0x10d451000 + 31918463
17  com.apple.CoreFoundation      	0x00007fff46c185e3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
18  com.apple.CoreFoundation      	0x00007fff46c18589 __CFRunLoopDoSource0 + 108
19  com.apple.CoreFoundation      	0x00007fff46bfbf3b __CFRunLoopDoSources0 + 195
20  com.apple.CoreFoundation      	0x00007fff46bfb505 __CFRunLoopRun + 1189
21  com.apple.CoreFoundation      	0x00007fff46bfae0e CFRunLoopRunSpecific + 455
22  com.apple.Foundation          	0x00007fff48e51a9f -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 280
23  com.github.Electron.framework 	0x000000010f2c255d 0x10d451000 + 31921501
24  com.github.Electron.framework 	0x000000010f2c149e 0x10d451000 + 31917214
25  com.github.Electron.framework 	0x000000010f23f465 0x10d451000 + 31384677
26  com.github.Electron.framework 	0x00000001121104f6 0x10d451000 + 80475382
27  com.github.Electron.framework 	0x000000010f0b5f29 0x10d451000 + 29773609
28  com.github.Electron.framework 	0x00000001104a9aad 0x10d451000 + 50694829
29  com.github.Electron.framework 	0x000000010f0b5154 0x10d451000 + 29770068
30  com.github.Electron.framework 	0x000000010d453f14 AtomMain + 84
31  com.github.Electron.helper    	0x000000010d44ef10 0x10d44e000 + 3856
32  libdyld.dylib                 	0x00007fff730743d5 start + 1

fsevent version is 1.2.8:

src/joplin
└─┬ chokidar@2.1.5
  └── fsevents@1.2.8

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 2
  • Comments: 27 (17 by maintainers)

Commits related to this issue

Most upvoted comments

This is an issue specific to v2.x I still haven’t found the root cause, but it looks like thread timing when it goes from 1 to 0 and back to 1 watchers, where the shutdown tis “interrupted” by a new startup.

So backporting is not an issue, I “just” have to find the actual cause and it’s doing my brain in.

+2
pipobscure on Jun 24, 2019

@pipobscure chokidar 3 is out, i’ll probably write a blog post about it.

+2
paulmillr on Apr 30, 2019

This may or may not be related:

https://github.com/paulmillr/chokidar/issues/859

Using the test script in that ticket, if you reduce the sleep time you can reliably make it crash. With longer sleep times (like 1000 ms) it doesn’t crash but it sometimes just gets stuck. There is the tail of a dtruss log in the comments that shows the sys calls when it gets stuck. All the calls there relate to threading, the last one of which relates to terminating a thread.

+1
ssh-peppe on May 31, 2019

@pipobscure Thank you very much for the offer!

Here’s what you’d need, and there’s a step-by-step with Screenshots, just in case:

  1. Zotero with BetterBibTex installed, and a few items in the library (I’ve got several hundreds, but I don’t think the number is important here)
  2. Export the full library using BetterBibTex to CSL JSON and tell BBT to keep the file updated at all times (I think that is where the other file watcher from the Zotero side attaches itself to the library file)
  3. Import the library to Zettlr in the Preferences
  4. Keep Zettlr open and begin to change the Zotero items – add tags, change the title, add other information, rename attachments – basically anything seems to trigger the crash. After some changes Zettlr will crash with the above mentioned crash report. The first changes will be detected by Zettlr correctly and it will re-load the library file.

P.S.: Someone mentioned somewhere that fsevents disseminates some events twice; I always receive two events that the library file has changed – I always thought that maybe BBT is writing the file twice, but now that I saw it it may also be a case of these twin-events!

EDIT: Zettlr also instantiates Chokidar at another point, here, in case there may be intereferences if Chokidar is called twice from within the same Node process!

+1
nathanlesage on May 18, 2019

@pipobscure yes, I will try to crash it with chokidar v3 in about 12h.

+1
tessus on May 1, 2019
Read more comments on GitHub
← fsevents: dyld: lazy symbol binding failed: Symbol not found: _FSEventStreamCreate
fsevents: fsevents fails to build →