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).