Deleting file in a project tree-view crashes editor

[GrishaKirilin]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

Starting with Pulsar 1.131.0 (upgraded to Electron 30), deleting a file in the project tree view has caused the editor to crash every time. I have disabled all community packages and launched the editor with 'pulsar --safe', but the problem persists.

It is not related to this issue, as I use the "Deb" package.

Pulsar version

1.132.1

Which OS does this happen on?

🐧 Debian based (Linux Mint, Ubuntu, etc.)

OS details

Ubuntu 22.04.5 LTS x86_64

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

1. Open editor.
2. Switch to the tree-view (Ctrl+Shift+\).
3. Select file.
4. Push Backspace.

delete_file.mp4

Additional Information:

There are so many issues with the editor starting with Pulsar 1.131.0 that I cannot describe them all.

[Daeraxa]

I have seen this but it has been so sporadic and hard to reliably replicate. Sometimes it has no issue at all, sometimes it crashes as soon as you delete and sometimes it deletes then crashes some time after. It is worth noting that, at least in my case, the file does get moved to trash. So it isn't the trashing the item itself that is the problem.

With it starting in 1.131.0 and Electron 30 this does indicate that the fault may well be in the move to ``@electron/remote's shell.trashItem()` which, whilst I'm probably wrong, is used over the standard electron `shell.trashItem()` as it bridges it from the main process to the renderer process.

And this bit actually tracks, because whilst looking at this I managed to get Pulsar to freeze with this exact issue. It just so happened that I had two windows open and only one of them froze, the second was working just fine... So that might be what we are seeing, that using this bridged method is causing a problem somewhere.

More evidence for this is that I actually have an init.js script that uses the standard electron shell.trashItem() to clean up backed up config files, this can be called multiple times on every single startup and it never has an issue.

As for how to investigate it? Properly I have no idea but below is my log of me flailing around trying stuff to see if it reveals anything.

Crashdump

It did generate a crashdump in .pulsar but damned if I know how to read it.

Finding some kind of error message

I did try running the binary in a terminal (not via the pulsar.sh script) and I did see this pop up when I managed to replicate it again:

177026:0601/131656.010042:ERROR:browser_main_loop.cc(280)] GLib-GObject: ../gobject/gsignal.c:2700: instance '0x1c30038a7e40' has no handler with id '3166'

Then this showed when I killed the process:

[177026:0601/131806.360317:ERROR:browser_main_loop.cc(280)] GLib-GObject: ../gobject/gsignal.c:2700: instance '0x1c30038abc00' has no handler with id '3374'

Also interesting to note here was that, I assume because I'm launching via terminal and not my desktop shell, when the window came up to kill the unresponsive application it only killed the "dead" renderer process, leaving my second window alive and the main process running in my terminal. Further proved by when I did a ctrl + c in the terminal:

Attempting to call a function in a renderer window that has been closed or released.
Function provided here: worker-manager.js:295:26
Remote event names: destroyed, crashed

Dev tools console

Nothing comes up when replicating this with the dev tools in that crashed window. They do however main responsive even when the main window is frozen but you can't "talk" to the dead process (e.g. making it do something like atom.notifications.addFatalError('A message');). The elements tab is also blank so something clearly isn't right there.

I did get a new message in the terminal though

sendToFrame() failed: Error: Render frame was disposed before WebFrameMain could be accessed
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: background-tips-view.js:30:29
Remote event names: blur, focus
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: worker-manager.js:295:26
Remote event names: destroyed, crashed

Looking at the main process

Tried attaching the chrome dev tools to inspect if anything funky showed in the main process console but nothing came up.

Using the electron/remote method from the dev tools

const { shell } = require('@electron/remote');
await shell.trashItem("/path/to/file.md");

And this works just fine... but is this because I'm calling it within the dev tools window directly??? Or is this just a problem with how this is being done with tree-view?

My best guess...

So my best and probably overconfident and uneducated guess is something weird going on between Electron and these GTK GObject IDs. When using shell.trashItem() directly there is no issue. But there is in the GUI. One difference is that in the latter we see dialog boxes but in the former we don't. Is there a problem here in what Pulsar is expecting from GTK is incorrect and causing things to break?

I want to look more into this gobject/gsignal ID but don't know how to start investigating it...

However... is all this pointless? Will #1564 solve the issue? I did try checking out 1564 and editing the tree-view package in node_modules directly from shell.TrashItem to atom.trashItem but it is exactly the same behaviour. So either it doesn't solve the problem or this wasn't the right way of trying it.

So no answer to the issue but maybe enough for somebody to get some info out of.

[savetheclocktower]

@GrishaKirilin, do you have any crash dumps in your ~/.pulsar/crashdump folder? The amount of crashing you're reporting is unusual and difficult to reproduce, so a crash report would be the best bet toward getting this diagnosed. If one is present in that folder after such a crash, please attach it to this issue. (If it's too big, we'll work out another means of transfer.)

[GrishaKirilin]

OK. Here is more info.

1. I forgot to mention that the editor only crashes if a deleted file was open in a pane. It's okay to delete a file that isn't displayed.
2. Today, there was a special crash that produced meaningful information in the terminal.

/usr/bin/pulsar: line 291:  7610 Segmentation fault      (core dumped) nohup "$PULSAR_EXECUTABLE" --executed-from="$(pwd)" --pid=$$ "$@" --no-sandbox > "$ATOM_HOME/nohup.out" 2>&1
Starting crash reporter; crash reports will be saved to /home/grisha/.pulsar/crashdumps
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
[0602/111351.056680:ERROR:elf_dynamic_array_reader.h(64)] tag not found

3. I run the executable directly /opt/Pulsar/pulsar --safe xxx/ and got the following error message:

Starting crash reporter; crash reports will be saved to /home/grisha/.pulsar/crashdumps
sendToFrame() failed: Error: Render frame was disposed before WebFrameMain could be accessed
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: background-tips-view.js:30:29
Remote event names: blur, focus
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: worker-manager.js:295:26
Remote event names: destroyed, crashed

4. GitHub doesn't allow me to upload even a tiny files, so I have uploaded all 280 dumps (including the one from the previous point) to Dropbox. Let me now if you can download them https://www.dropbox.com/scl/fo/by1awp2wg1ed89dzr073f/AOgbRO23oz3UMJheAfUQpjQ?rlkey=yj3vomdg8vdyyyojgjs46u263&st=xlgl2f4g&dl=0

The first dump appeared in 19th of February.

[savetheclocktower]

@GrishaKirilin, I have a theory that this is related to the library we use for subscribing to filesystem events.

One way to test this theory would be to use the binaries from #1572. We plan to gradually migrate toward the filesystem events library that VS Code uses, but ultimately to allow that library to be configurable by the user. On this experimental version of Pulsar you've got more options for the “Core -> File System Watcher” setting. I'd recommend setting it to “@parcel/watcher” — but even if you leave it on nsfw, this build would likely stop crashing altogether if my theory is right, since file-watching will now happen in a worker process no matter which option you pick.

If you're interested in testing this, visit this CI job and download the “ubuntu-latest Binaries” artifact, then pick the one that fits best with your platform (probably the .deb, or perhaps the .tar.gz for something more temporary).

[jucajuca]

I can confirm the issue and provide crash dumps. Compressed because github does not allow .meta or .dmp

@savetheclocktower

dumps.zip

Update

So I downloaded the binaries from here https://github.com/pulsar-edit/pulsar/actions/runs/26203634471?pr=1572 and it still crashed when I deleted a file.

Dumps after update:

new-dumps.zip

[savetheclocktower]

OK, this narrows it down to pathwatcher. The bad news is that the binaries from that CI job don't touch pathwatcher (they involve the other file-watcher) and that's why they don't help.

The good news is that pathwatcher is 100% under our control, so this is fixable once we figure out why it's happening.

Thanks so much to both of you for helping us narrow this down, and I'm sorry for the hassle.

[savetheclocktower]

I have not been able to reproduce this issue in a VM. I’m on an Apple Silicon machine running Ubuntu 22 (arm64), so that might have something to do with it.

I will keep trying to diagnose this issue via crashdump. In the meantime: if you are motivated to discover the root cause, you can try these steps…

1. Ensure gdb is installed; if not, sudo apt install gdb (assuming Ubuntu)

2. Launch Pulsar

3. Open the developer tools (Ctrl-Shift-I) and type process.pid in the console; note the number. Close developer tools.

4. Switch to a terminal and run this command, substituting the number you just noted for [pid]:

   sudo gdb -p [pid]
   

5. Once gdb launches, run these commands. (First you’ll tell it to intercept SIGTRAP; then, when it asks if you’re sure, type y; then continue resumes execution of the renderer process.)

   handle SIGTRAP stop print nopass
   y
   continue
   

6. Proceed with the steps that produce the crash — i.e., deleting a file from the tree view.

7. If the crash happens, switch back to the terminal; hopefully gdb will have caught the signal, and Pulsar won’t have exited — just frozen. If so, run

   thread apply all bt
   

   and then copy and paste the output into this issue.

[savetheclocktower]

Actually, I'm now able to reproduce this crash. Feel free to wait on the steps above; I'll follow them myself with a debug build when I get a chance.

[savetheclocktower]

OK, my new hypothesis is leading me away from pathwatcher and towards @electron/remote as the core cause. We use it to do things that you ordinarily can't do from the renderer process — like moving files to the trash.

This CI job is building some binaries that might fix this. (Deja vu, I know.) When it's done, let me know if this fixes your issue. (This bypasses @electron/remote by calling new specific methods defined in the renderer that ask the main process to move the file to the trash on our behalf.)

[savetheclocktower]

OK. The crash is sporadic on my side, but I was able to get some crashdumps locally and then combine them with debug symbols from electron and pathwatcher for analysis.

Claude’s best hypothesis at this point (Claude is much better at crashdump analysis than I am) is that this is almost certainly a bug related to memory allocation within our pathwatcher library. That’s a filesystem watcher we use for detecting when files have been updated, deleted, moved, and added.

So I have removed “red herring” status from pathwatcher and am back to accusing it of treachery.

On both Windows and Linux, pathwatcher delegates to a cross-platform library called EFSW that tries to abstract away the differences between file-watching implementations on those platforms. EFSW’s Linux adapter uses inotify, but tries to make it support things that inotify doesn't support natively, like recursive filesystem watching.

We used to use EFSW for all three platforms, but responded to a macOS EFSW bug by writing our own file-watching implementation and swapping it in. So it’s probably time to do the same on Linux. This is an appealing option because we have simpler file-watching needs than what EFSW tries to deliver, so we can probably simplify the implementation in the process.

That’s what I’ve done in pulsar-edit/node-pathwatcher#7. The next step is to produce a draft PR that points at this custom pathwatcher branch just so we can get a binary built that hits our new code path here. Then we can figure out whether that build suffers from this issue.

I’ll comment again when that PR build is ready.

[savetheclocktower]

OK, it'll be this job. Crossing my fingers.