pulsar-edit
crashes on Ubuntu 24.04 with segfault and "non-context-aware native module" warnings
Summary: The Pulsar editor version 1.130.1 crashes on Ubuntu 24.04. The crash is accompanied by a segfault error in the kernel log and repeated "non-context-aware native module" warnings in the nohup.out log file. Environment: Pulsar Version: 1.130.1 Electron: 12.2.3 Chrome: 89.0.4389.128 Node: 14.16.0 Operating System: Ubuntu 24.04 Desktop Environment: GNOME Shell 46.0 Hardware: 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz Steps to Reproduce: Open the Pulsar editor. The editor crashes and displays the "The editor has crashed" dialog. Expected Behavior: The Pulsar editor should keep running without crashing, and the action in step 2 should succeed. Actual Behavior: The editor crashes and shows a dialog indicating a crash. The logs reveal a segmentation fault and several Electron warnings.
installed packages Git Packages (22) ├── [email protected] (steelbrain/busy-signal#3f4dca56) ├── [email protected] (Pulsar-Edit-Highlights/selected#1f940a05) ├── [email protected] (steelbrain/intentions#c6f9507b) ├── [email protected] (steelbrain/linter#9011326c) ├── [email protected] (steelbrain/linter-ui-default#136d151c) ├── [email protected] (atom-minimap/minimap#55460b3b) ├── [email protected] (ansballard/minimap-autohider#eddeedae) ├── [email protected] (atom-minimap/minimap-bookmarks#1b27bd7b) ├── [email protected] (olmokramer/atom-minimap-codeglance#d5bcd520) ├── [email protected] (atom-minimap/minimap-cursorline#40408cb1) ├── [email protected] (atom-minimap/minimap-find-and-replace#78c90e94) ├── [email protected] (atom-minimap/minimap-git-diff#37e4d435) ├── [email protected] (T-800/atom-minimap-hide#f473f9dd) ├── [email protected] (atom-minimap/minimap-highlight-selected#21dfd6ae) ├── [email protected] (AtomLinter/atom-minimap-linter#a1e52d14) ├── [email protected] (abe33/minimap-pigments#c9d9aecf) ├── [email protected] (gouegd/atom-minimap-quick-highlight#3e4e298e) ├── [email protected] (atom-minimap/minimap-selection#0a49c578) ├── [email protected] (mupchrch/minimap-split-diff#14b912f5) ├── [email protected] (t9md/atom-quick-highlight#cccbb19b) ├── [email protected] (mupchrch/split-diff#d4bb0f1f) └── [email protected] (Spiker985/x-terminal-reloaded#ea1e8d41)
After a while, the same behavior is observed
undo > redo caused a crash
I don't know what else to include
Had you been using a previous version of Pulsar that did not exhibit this issue? If so, which version?
The only other version of Pulsar I've used was pulsar_1.107.2023072523_amd64, but that was a while ago, and I don't remember much using it.
The only other advice I have right now is to try PulsarNext (preview release of Pulsar that uses Electron 30 instead of Electron 12) to see if this has been addressed. Grab the latest binary on this page that matches your platform and processor architecture.
PulsarNext has crash reporting built in, so if it does crash, you'll at least have a crashdump that you can attach. There are some caveats, as explained here, but if the crash is happening that suddenly, it'll be pretty easy to determine whether PulsarNext exhibits the same problem.
If it doesn't, then you're in luck, because we'll be bringing this update to mainline Pulsar very soon. If it still crashes, at least we'll be able to track down a crashdump.
i try to attach the .dmp file, but it's not uploading
Do you use Discord? If so, hop on our channel and ping me in #general (same user name). Maybe you'll be able to send it to me that way. If not, we'll figure something else out.
@SpeedrunnerG55, from what I can tell, your segfault is happening because of an out-of-memory error. The dump implies that one of your editor windows is trying to open an absolutely gigantic file. This would explain why it's happening with both Pulsar and PulsarNext, even though superstring (our text buffer library) changed quite a bit between these two versions.
If I saw this stacktrace and knew only that it happened to a user shortly after startup, I'd suspect that Pulsar was trying to restore a project it had open a while ago, and that somehow it was trying to load a very, very, very large file into a text buffer, even if the user didn't ask it to. But from the available evidence, there isn't a “smoking gun” for that theory, so I bet it's something more subtle than that.
Some questions:
- Can you tell me about this
protonCtlv.1.1.4.shfile? How big is it? (If it's a shell script, I imagine it can't be as big as this stack trace suggests.) - Are you able to open Pulsar without having this file open upon startup? If it always shows up when you execute
pulsar, trypulsar --clear-window-state. It looks as though, even when you ran it in safe mode, this file was always present in the workspace. I'm curious if you can replicate this crash with a single empty buffer. - Is your project directory your home folder? (Is
protonCtlv.1.1.4.shpresent at~/protonCtlv.1.1.4.sh?) In the past we've seen some unusual behavior when people open a project (intentionally or unintentionally) with their entire home folder as the root. I'm curious what happens if you copy~/protonCtlv.1.1.4.shto, say,~/tmp/protonCtlv.1.1.4.sh, thencd ~/tmpand runpulsar ..
After further discussion on Discord, it seems that the issue is triggered by editing a very large shell script (3,000+ lines) and making heavy use of the undo/redo stack. Based on the symptoms, every invocation of undo or redo seems to result in increased memory usage.
We've given @SpeedrunnerG55 some tools to keep an eye on their memory usage and figure out when it's increasing. The next step, I think, would be to teach them how to take heap snapshots in the developer tools so that we can get some before/after snapshots to inspect.
That said, I'm still perplexed; I don't have any good ideas about what the exact mechanism could be. The entire process of developing modern Tree-sitter mode involved me spending 80% of my time in a single 5,600-line JavaScript file, and there were often times that undo/redo was used liberally. Yet I never had issues of this nature.
One thing I'm curious about is whether it has anything to do with shell scripts specifically, or whether the symptoms would be similar if this were a large file in some other language. I'm sure that a bash script is challenging to parse (the tree-sitter-bash parser produces a larger-than-average .wasm file). But from experience, out-of-memory scenarios in WebAssembly have different symptoms and are much less catastrophic. They certainly don't result in segfaults.
So my money's on an old-fashioned memory leak. Maybe the key is to find a big shell script in the wild, try to reproduce the editing conditions, and measure the effects on our own machines.