Pulsar 1.104.2023042014 is built for 4K pagesize and segfaults on 16K arm64 systems
Thanks in advance for your bug report!
- [X] Have you reproduced issue in safe mode?
- [X] Have you used the debugging guide to try to resolve the issue?
- [X] Have you checked our FAQs to make sure your question isn't answered there?
- [X] Have you checked to make sure your issue does not already exist?
- [X] Have you checked you are on the latest release of Pulsar?
What happened?
Pulsar is built for 4K pagesize and segfaults on 16K arm64 systems:
$ pulsar
$ /usr/bin/pulsar: line 163: 262468 Segmentation fault nohup "$PULSAR_PATH" --executed-from="$(pwd)" --pid=$$ "$@" --no-sandbox > "$ATOM_HOME/nohup.out" 2>&1
Program headers:
$ readelf --program-headers /opt/Pulsar/pulsar
Elf file type is DYN (Position-Independent Executable file)
Entry point 0x1921000
There are 12 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000002a0 0x00000000000002a0 R 0x8
INTERP 0x00000000000002e0 0x00000000000002e0 0x00000000000002e0
0x000000000000001b 0x000000000000001b R 0x1
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000191ffe4 0x000000000191ffe4 R 0x1000
LOAD 0x0000000001920000 0x0000000001921000 0x0000000001921000
0x0000000005aa0610 0x0000000005aa0610 R E 0x1000
LOAD 0x00000000073c0610 0x00000000073c2610 0x00000000073c2610
0x000000000048d638 0x000000000048d638 RW 0x1000
LOAD 0x000000000784dc48 0x0000000007850c48 0x0000000007850c48
0x0000000000067628 0x000000000013f500 RW 0x1000
TLS 0x00000000073c0610 0x00000000073c2610 0x00000000073c2610
0x0000000000000018 0x0000000000000098 R 0x8
DYNAMIC 0x000000000782bb78 0x000000000782db78 0x000000000782db78
0x0000000000000400 0x0000000000000400 RW 0x8
GNU_RELRO 0x00000000073c0610 0x00000000073c2610 0x00000000073c2610
0x000000000048d9f0 0x000000000048d9f0 R 0x1
GNU_EH_FRAME 0x000000000191790c 0x000000000191790c 0x000000000191790c
0x00000000000017e4 0x00000000000017e4 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x00000000000002fc 0x00000000000002fc 0x00000000000002fc
0x0000000000000064 0x0000000000000064 R 0x4
"0x1000" in Align column means 4K.
See also https://github.com/microsoft/vscode/issues/153849#issuecomment-1200666873
Pulsar version
1.104.2023042014
Which OS does this happen on?
🐧 Debian based (Linux Mint, Ubuntu, etc.)
OS details
Ubuntu 23.04 aarch64 / arm64
Which CPU architecture are you running this on?
Apple M2 Pro
What steps are needed to reproduce this?
just start 'pulsar' from terminal
Additional Information:
No response
This might be solved by just updating Electron. There is already a PR for that: https://github.com/pulsar-edit/pulsar/pull/484
Yeah this is known about, we can't support 16k kernels until we move to at least Electron 19/Chromium 21. We have plans to go onto newer electron versions anyway for a whole host of reasons so this will hopefully be resolved as part of it.
WOW - I would NEVER captured that much detail, good job @kaazoo
As for the newer Electron - I am personally using the newer version, but unfortunately a lot of our users depend on some packages that are not compatible with Electron >13 (this means that even bumping to Electron 14 will already break everything, and it seems we need Electron 19), so that's why we can't just "upgrade to the newest and be done with it" for now.
But - I'll keep working on keeping the new Electron "feature branch" up-to-date, and maybe we can even keep both versions at the same time - so feel free to use this version, just be aware that it might contain small bugs :)
Hello everyone, I quickly read your pleasant discussion. I must say that I have always found problems with programming on Raspberry, which is basically the platform (in reference to ARM) on which I would like to move the developments, with Pulsar I thought I had found the solution to everything, having discovered it after the closure of Atom (the only editor used after notepad.), since it supported ARM, but now I find myself with the same problem as the user who uses Apple. How long might it take to resolve in a stable manner? I add: It would be possible to integrate remote file management, natively, a bit like what happens in VS Code, I think I saw it there. (Maybe even a web version as in their case, but now I'm really dreaming.....)
What platform are you seeing this on? It is working fine on my Pi4 but I've not yet tried it on my Pi5 - is that what it is broken on? Either way we can't do much until we move to the new Electron version which we are talking about offering alongside the current one as a "bleeding edge" package.
Edit: Yup, Raspberry Pi OS for the Pi 5 is indeed using a 16k pagesize
@Crisaleo
"I add: It would be possible to integrate remote file management, natively, a bit like what happens in VS Code, I think I saw it there. (Maybe even a web version as in their case, but now I'm really dreaming.....)"
It is a bit off-topic for this bug, best to open a discussion or feature request but honestly so long as there is a community package for it I'm not sure we necessarily want to add it in as a default package.
Yes, I'm using Raspberry 5, is there an operating system for this version that isn't 16K? I fear this choice was also made for hardware compatibility... However it's fine for everything else, I understand! :-)
It seems the legacy RPi OS isn't compatible with the Pi5 - best bet would be going on the forums or something to see if there are alternatives that use 4k.
Is there any update on this? Some rough estimate of when it might be completed? Not trying to rush, just wanted to know if I should look for alternatives.
Is there any update on this? Some rough estimate of when it might be completed? Not trying to rush, just wanted to know if I should look for alternatives.
I am actively working on releasing a preview version of Pulsar that runs on Electron 30+. That should address this issue. It will be beta software, and there's a decent chance some of your community packages will need updating, but it should at least give you a way forward.
If things go well, it could be ready in the next month.