Editor crashes a few seconds after opening Pulsar if files are left open between sessions

[wdiasjunior]

I can only reproduce this with versions 1.131.0 and 1.131.1, using both the AppImage and the AUR package.
Running Arch Linux, KDE Plasma on X11 with electron version 39.5.2-1.

I'm still not sure what's causing this or if there are other ways to reproduce this, but here's what I'm doing:

1. open multiple repos in the project tree view
2. open multiple files from different repos
3. close Pulsar
4. open Pulsar
5. see crash dialog

Here's a pastebin with the crash dump from Plasma: https://pastebin.com/8MyE5xBC

I tried removing my customization from config.cson, keymap.cson, snippets.cson and styles.less, and even disabling packages but still got the same behavior.

I can still use the AppImage for version 1.130.1 without issues.

[savetheclocktower]

There isn't a bunch of wisdom to be gleaned from the crash report, but it's enough to demonstrate that this is unrelated to what we fixed in #1438. SIGABRT is typically sent on purpose when an assertion fails.

(I don't know about the AUR package, but the AppImage would use Electron 30.0.9, no matter what version of the Electron dependency is installed locally. The way to be sure is to invoke Application: About and click on the “Show More” link to see the reported Electron/Chrome/Node versions.)

I tried the reproduction instructions on macOS and was unsuccessful.

@wdiasjunior, I have one immediate suggestion: when you open Pulsar in step 4, open it via the terminal, and append -f --enable-electron-logging --v=1. That should log way more information to the terminal. If it crashes again, please create another pastebin with the entire terminal output. (If it's too much to fit in the terminal buffer, you can redirect it all to a file: -f --enable-electron-logging --v=1 > output.log.)

Other things you could try if you had large wells of patience

Your reproduction steps are interesting: a project with multiple roots, each of which is its own repo. Given repos A and B, I'm curious what happens if…

• …you open a sub-folder of repo A as a project root, then drag another sub-folder of A into the project. (Is it a function of multiple repos, or just multiple roots?)
• …you have two project roots, one of which belongs to repo A and one of which belongs to no repository. (Similar.)
• …you go to the shared ancestor directory of repos A and B and open that as a single root, then proceed with step 2 onward from the repro steps. (Can we trigger this crash with multiple repos and only one project root?)

Wouldn't blame you if you didn't feel like doing any of this, though.

Thanks for the report!

[savetheclocktower]

There might also be a separate dump in ~/.pulsar/crashdumps.

[wdiasjunior]

Thanks for the quick reply.
Forgot to mention in the first comment that I checked the crashdumps directory but only saw files in the pending subdirectory. So I cleaned the directory and reproduced the steps again.

I've zipped the .dmp and .meta files created for the crashdump.
1baf9326-d83e-4327-a560-92b91b53d1cf.zip

Running Pulsar with the flags you mentioned did result in logs in the terminal but the output file only contained the following:

Starting crash reporter; crash reports will be saved to /home/wjr/.pulsar/crashdumps
Renderer process crashed - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.

Pastebin of the terminal logs: https://pastebin.com/zPsZr3pk

I'll try to reproduce the issue with your other suggestions for project folders later today.

[savetheclocktower]

OK, the crashdump was quite useful.

The renderer process is running out of memory. WebAssembly specifically is asking for an increase in the amount of memory that is allocated to it, and that allocation fails.

We use WebAssembly mainly for Tree-sitter. This could be happening because it is trying to load more than one Tree-sitter parser at the same time (restoring an existing project state, including open buffers). Or it could be happening because the process of loading and parsing the buffer contents itself requires memory growth.

But I don't yet have a good answer for why this is happening on session restore — after all, step 1 of the repro instructions puts the editor into this state without itself triggering a crash. Claude theorizes that it's an issue of peak memory pressure — that V8 is overwhelmed by nearly simultaneous requests to load Tree-sitter parsers. It thinks that if the loading of parsers were staggered, that would smooth out the memory usage, meaning that the second load could reuse memory that was temporarily allocated during the first load instead of asking for even more memory. I'm skeptical, but I don't have a better theory at the moment.

@wdiasjunior, some more questions:

1. How much memory do you have on your machine?
2. How many files are open in your session? It sounds like it's just two. What languages are the files written in? (JS? C++? Markdown?)
3. Are the files especially long, or can you reproduce this issue just as easily by opening files of smaller size?

And one specific thing to try:

• Open core settings and temporarily uncheck “Use Tree-sitter Parsers.” Then relaunch Pulsar and repeat your repro steps to see if the crash still happens. That would help narrow down whether web-tree-sitter specifically is a factor in the crash. (Be sure to re-enable “Use Tree-sitter Parsers” afterward if you're willing to continue to diagnose this for us.)

If we identify that this is a Tree-sitter issue, then I'm betting we can learn more by experimenting with the languages of the buffers that are left open. Some kinds of files (HTML files, for example, or Markdown files with lots of fenced code blocks) necessarily end up loading lots of Tree-sitter parsers; so if the crash doesn't happen on simpler files (even when we're using Tree-sitter grammars), then that would indicate we're on the right track.

[wdiasjunior]

@savetheclocktower

1. 48GB of memory.

2. I did a more thorough test and I'm able to reproduce this with just 3 (kinda big) markdown files open. I usually keep some long .md (never longer than 1000 lines) docs open along with whatever .tsx and .go files I'm working on.
   Now that I think about it, having more than one repo per project is probably not affecting this, since all of the .md files that seem to cause the issue were from the same repo. I then tried opening around 30 small .md files from 1 to 10 different repos and it did not cause a crash just by the amount of files, but then with the ~30 files open I opened a 900 line .md file and it crashed on startup.

3. I don't think long files specifically are the culprit here, maybe just tree-sitter being weird with long markdown parsing. I tested this with a 5k line .json along with a bunch of .tsx files and it did not cause the crash to happen.

Disabling "Use Tree-sitter Parsers" does seem to prevent the crashes. I'll try to stress test this more later.

A bit unrelated to this issue but, back when the new implementation of tree-sitter was introduced I noticed some changes to the way it handled syntax highlighting and it always felt weird to me that it changed the colors of keywords in some languages compared to no tree-sitter or the the legacy version, so I just kept using the legacy until now. Just guessing here but I'm probably only seeing this bug now with the removal of the legacy version and I'm trying the new one with this niche use case.

Btw, what are the advantages here by using tree-sitter parsers?

[savetheclocktower]

It's great that you have a workaround. You don't have to turn off Tree-sitter parsers altogether; you can check that box again, then disable Tree-sitter only for Markdown files (see #878 and the heading “I want to go back to the old highlighting!”).

And you have a bunch of memory, too, so this isn't likely to be an issue that's constrained to your particular machine. That's good because it strongly implies we'd be able to replicate this issue in a VM with some Markdown files designed to stress-test the parser.

Thanks for opening this issue and being willing to experiment! I'll leave it open for now because I'm pretty motivated to try to reproduce this in a VM somehow.

---

Btw, what are the advantages here by using tree-sitter parsers?

In general, Tree-sitter is way better at understanding code. You can get very specific with how you apply syntax highlighting. It also allows for much simpler systems for describing indentation hinting and code folding; and it can also be used as a symbol provider for the builtin symbols-view package.

Until 1.131, there were three kinds of grammars:

• Original grammars based on the format invented by TextMate; based entirely around regular expressions.
• Legacy Tree-sitter grammars written when the Atom team first tried to migrate to Tree-sitter; these grammars did not have great ways of targeting tokens for syntax highlighting and were often a step backward from what people were used to.
• Modern Tree-sitter grammars based on a newer version of Tree-sitter with a robust query language. These grammars are designed to be as descriptive as TextMate grammars while taking advantage of all of Tree-sitter’s features.

It sounds like you had enabled the “Use Legacy Tree-sitter Implementation” setting that just got removed. Those parsers had rudimentary support for highlighting, but otherwise relied on TextMate’s systems for indentation and code folding. I'm sure they would've improved over time, but Atom was de-prioritized after Microsoft bought GitHub, and Tree-sitter's creator stopped working on Atom altogether.

We understood that making modern Tree-sitter grammars the default would be disorienting to people, just like it was disorienting when the Atom folks moved to the original Tree-sitter grammars. Where possible, we tried to mitigate that with corresponding changes to built-in syntax themes. Still, there are any number of reasons why the highlighting changed with modern Tree-sitter grammars:

• Legacy grammars were written at different times by different people. Most of the modern Tree-sitter grammars were written by me in the span of a year, and I took the opportunity to increase cross-language consistency in how we highlighted things.
• Going past simple matters of consistency: some of the legacy grammars (of both kinds) were just wrong in how they assigned highlighting scopes. I'm glad it works for you, but the legacy language-markdown TextMate grammar was written by someone who seemed to make scope naming decisions on pure whimsy, or perhaps how it made the code look in their own favorite theme.
• Sometimes it was impossible to highlight things “properly” in a TextMate grammar because of limitations that were no longer relevant for Tree-sitter. (For instance, we now have much more latitude to highlight variables, even in languages where variables don't start with a sigil like $. In TextMate grammars it's hard to do this because you're basically describing patterns that would match every single word in the file.)

Ironically, one of the major upsides of Tree-sitter is how it handles Markdown, at least in theory! Since all HTML is valid Markdown, you're able to mix inline HTML into any Markdown paragraph, or dip into HTML entirely for things that Markdown can't represent. That makes it very hard to syntax-highlight correctly with a traditional grammar's pattern-matching tools. Our modern Tree-sitter grammar for Markdown can parse the parts that are Markdown, then identify the parts that are HTML and delegate them to the HTML grammar to highlight.

[johnb432]

I'm also experiencing crashes when restoring a project with open markdown files (both the source and the preview). I haven't dug any deeper to figure out what the exact issue is though. Turning off the tree-sitter parsers indeed circumvents the issue. However, I'm on Windows 11.