Segfault on InotifyBackend::handleSubscription about watcher HOT 4 OPEN

Sorry I provided a coredump thinking you could use it, but now I realise it's not really possible. I'll try to get a coredump with a debug build and extract meaningful information from it, like full stack state, local variables, and precise line numbers, and I'll come back to you then but it might take some time since I don't know when the next crash will happen:(

from watcher.

Thanks for the report. One thing you could try would be to use a debug build to get a more accurate backtrace. You could do this by cloning the repo locally and running yarn && yarn rebuild (or npm install && npm run rebuild). Then use yarn link/npm link to link the local version into your project. Then you can run your program inside gdb or lldb and get a backtrace hopefully. Thanks in advance!

from watcher.

I have a coredump for the debug build now. I looked a bit with vscode inside it and found the segfault to be there:

I guess at some point the watcher data has been corrupted, but I have no clue yet on why it happened. If you want more detail or have any idea on where to look I'm all ears!

from watcher.

@devongovett Some more insight.

Just to add some context, the way I use this library is having multiple subscriptions to multiple directories. When I start my application, I start watching these directories with one subscription for each:

.
├── a
├── b
├── c
├── ...

So basically, what I do is this somewhere in my code:

const subscriptions = await Promise.all(
  directories.map(
    (directory) => watcher.subscribe(directory, (err, events) => processFn(directory, err, events)
  )
);

Then later my code will produce some artifacts, and when everything is done I want to save a snapshot of the filesystem. So it looks like that:

const processFn = async (directory, err, events) => {
  // Do some stuff
  await processEventsAsync(events);

  // Save a snapshot
  watcher.writeSnapshot(
    directory,
    someFilePathThatDontInterfereWithWatchingInAnyWay
  )
}

So first remark here, I know that what I do differs with what you do with parcel (v2) since in parcel there is two assumptions:
(A1). You watch only one directory: projectRoot (if I remember well).
(A2). You write a snapshot only once, when parcel is exiting.

I have my reasons to save a snapshot everytime file changes, cause my code rely heavily on caching and I didn't want to pay the price of my code exiting too soon without updating the snapshot.

With this context in mind, what pops in my eyes now in the screenshot is that:

mWatched: false

Looking at the code it means that either mWatched were never true, either this line has been called:

There are many places where this code can be called but not that much. Given the context, the place that I find interesting is this one:

Indeed, recall that the segfault is on this line:

So it means that we are currently processing some input events has part of the process of watching.

But like the coredump tells us, it seems the watcher instance is corrupted, ie. maybe at this point the C++ object has been destroyed because of an unref calls, which will trigger this line:

So maybe this segfault is really a race condition between a subscription beeing active, and calls to writeSnapshot, all of them with the same dir and ignore parameters.

If this is the case, the reason why my code crash from time to time is that I am violating condition (A2), which can lead to this segfault.

What do you think ?

EDIT: another coredump today, same problem with also a corrupted watcher. Also I realized that having the mWatched property true or false doesn't mean anything since the watcher is corrupted.. But I still think there is something true about my reasoning, waiting for your input;)

from watcher.