Crash Zettlr 3.10 about zettlr

[nathanlesage]

I have now downgraded Electron to 29.3.2 which, at least on my system, launches fine. I'll immediately schedule a manual nightly build, and request that all of you who have this issue try this one out -- just to see if it still segfaults. If it doesn't, I'll release a hotfix that downgrades Electron to 29.3.2 so that we can all use the app again.

[nathanlesage]

Perfect, I'll be releasing 3.1.1 soon that ships with this fix in a "regular" release so that others who run Linux but require a package manager will soon also be able to use the 3.1.x release line.

[dustdfg]

Please try out the last beta, it uses basically the same code but with a slightly older Electron version, that one should work while we wait for Electron to fix this 🍵

It works in my case

[w-wagner]

nightly:
Opening as window, maximized and via -m works now. Very good.
The error, when I close it is still there and makes the restart after clear Help - Clear FSAL Cache impossible.

[alerque]

I was reluctant to bump the Arch Linux package that involved downgrading ELectron for a bug that I couldn't reproduce, but if the crash is Xorg specific and I'm on Wayland that does explain that. I'll have a look ... but yes the thing to do for this would have been file a bug report on our issue tracker.

[nathanlesage]

There seems to be a patch incoming that should allow us to swiftly move to Electron 30/31. I'll be launching a nightly soon to confirm, please stay ready to test it so we can release a stable fix.

[dustdfg]

Works after update...

[dustdfg]

I just made a reboot and problem returned

[m1ga]

Same issue here Linux fedora 6.8.7-300.fc40.x86_64
Doesn't start and shows the same crash.

[miga@fedora ~]  $ zettlr 
[Application] Performing environment check ...
[Application] Pandoc has been bundled with this release. Path: /usr/lib/zettlr/resources/pandoc
[Application] Quarto not found on system. *.qmd-files will be exported with Pandoc.
[Application] Environment check complete.
Speicherzugriffsfehler (Speicherabzug geschrieben)

[nathanlesage]

That looks suspiciously like an error in Electron. Maybe this one

[nathanlesage]

Please try out the last beta, it uses basically the same code but with a slightly older Electron version, that one should work while we wait for Electron to fix this 🍵

[m1ga]

in Fedora it won't let me install zettlr-3.1.0.beta.3-1.x86_64 as it conflicts with Slack slack-4.37.101-0.1.el8.x86_64 (Slack runs fine).

[nathanlesage]

Ah jesus, how I hate these stupid package conflicts … there's not much I can do then except wait :/

[dustdfg]

That looks suspiciously like an error in Electron. Maybe this one

I am not sure that it is exactly this error because I use sway and when I open zettlr through terminal it opens it in half screen because sway is tiling manager

[nathanlesage]

That looks suspiciously like an error in Electron. Maybe this one

I am not sure that it is exactly this error because I use sway and when I open zettlr through terminal it opens it in half screen because sway is tiling manager

The issue talks at some point about issues with tiling managers, so there is a chance this is related.

[LaPingvino]

I run Gnome on Wayland and I can confirm that both Gnome on Wayland and Hyprland have it working properly. I can reproduce the segfault with Gnome on Xorg on my Arch Linux system with an official build from the package manager. The bug doesn't seem to appear with the AppImage version.

@dustdfg and @m1ga can you see if the AppImage version works as a workaround?

[LaPingvino]

it seems to reliably trigger if I try to run any version with the disable hardware acceleration flag

[dustdfg]

I run Gnome on Wayland and I can confirm that both Gnome on Wayland and Hyprland have it working properly. I can reproduce the segfault with Gnome on Xorg on my Arch Linux system with an official build from the package manager. The bug doesn't seem to appear with the AppImage version.

@dustdfg and @m1ga can you see if the AppImage version works as a workaround?

The same result with appimage

[w-wagner]

I just tried --clear-cache and second, removed .config/Zettlr completely.
It did not help.

When I started without the Zettlr confir dir the output changed to
zettlr
[Application] Performing environment check ...
[Application] Pandoc has been bundled with this release. Path: /usr/lib/zettlr/resources/pandoc
[Application] Quarto not found on system. *.qmd-files will be exported with Pandoc.
[Application] Creating required directory /home/wolfram/.config/Zettlr/dict ...
[Application] Creating required directory /home/wolfram/.config/Zettlr/lang ...
[Application] Creating required directory /home/wolfram/.config/Zettlr/logs ...
[Application] Creating required directory /home/wolfram/.config/Zettlr/defaults ...
[Application] Creating required directory /home/wolfram/.config/Zettlr/snippets ...
[Application] Creating required directory /home/wolfram/.config/Zettlr/lua-filter ...
[Application] Environment check complete.
[8699:0505/074018.026679:ERROR:nss_util.cc(357)] After loading Root Certs, loaded==false: NSS error code: -8018
Speicherzugriffsfehler

3.0.5 did work immediately before the update.
(fully updated debian 12.5, xorg, cinamon)

[nathanlesage]

After loading Root Certs,

This sounds fishy, why would that produce a segfault? 🤔

[w-wagner]

zettlr_out.txt
Just reverted to 3.0.5 deb and it worked. Back to 3.1.0 and the segfault reappears.

I also have tried the other startup parameters.
It crashes when it tries to display the window. If I start it with "-m" (minimized) it opens up and does not crash,
until I choose "Show Zettlr" from the context menu (right click on the taskbar icon).

Ok, now, it does not crash anymore, when I start with -m and display the window.

But it crashes, when I close it:
A lot of incomprehensible text (looks somehow like a compiled source code archive?) is printed in the console than:
RangeError: Maximum call stack size exceeded
(Use zettlr --trace-uncaught ... to show where the exception was thrown)

The text looks like

(a lot in front...)
璉璟甁畯皂皜皞皛皦益睆劯砡硎硤硺礰礼神祥禔福禛竑竧靖竫箞精絈絜綷綠緖繒罇羡羽茁荢荿菇菶葈蒴蕓蕙"],["ee80","蕫﨟薰蘒﨡蠇裵訒訷詹誧誾諟諸諶譓譿賰賴贒赶﨣軏﨤逸遧郞都鄕鄧釚釗釞釭釮釤釥鈆鈐鈊鈺鉀鈼鉎鉙鉑鈹鉧銧鉷鉸鋧鋗鋙鋐﨧鋕鋠鋓錥錡鋻﨨錞鋿錝錂鍰鍗鎤鏆鏞鏸鐱鑅鑈閒隆﨩隝隯霳霻靃靍靏靑靕顗顥飯飼餧館馞驎髙髜魵魲鮏鮱鮻鰀鵰鵫鶴鸙黑"],["eeef","ⅰ",9,"￢￤＇＂"],["f040","",62],["f080","",124],["f140","",62],["f180","",124],["f240","",62],["f280","",124],["f340","",62],["f380","",124],["f440","",62],["f480","",124],["f540","",62],["f580","",124],["f640","",62],["f680","",124],["f740","",62],["f780","",124],["f840","",62],["f880","",124],["f940",""],["fa40","ⅰ",9,"Ⅰ",9,"￢￤＇＂㈱№℡∵纊褜鍈銈蓜俉炻昱棈鋹曻彅丨仡仼伀伃伹佖侒侊侚侔俍偀倢俿倞偆偰偂傔僴僘兊"],["fa80","兤冝冾凬刕劜劦勀勛匀匇匤卲厓厲叝﨎咜咊咩哿喆坙坥垬埈埇﨏塚增墲夋奓奛奝奣妤妺孖寀甯寘寬尞岦岺峵崧嵓﨑嵂嵭嶸嶹巐弡弴彧德忞恝悅悊惞惕愠惲愑愷愰憘戓抦揵摠撝擎敎昀昕昻昉昮昞昤晥晗晙晴晳暙暠暲暿曺朎朗杦枻桒柀栁桄棏﨓楨﨔榘槢樰橫橆橳橾櫢櫤毖氿汜沆汯泚洄涇浯"],["fb40","涖涬淏淸淲淼渹湜渧渼溿澈澵濵瀅瀇瀨炅炫焏焄煜煆煇凞燁燾犱犾猤猪獷玽珉珖珣珒琇珵琦琪琩琮瑢璉璟甁畯皂皜皞皛皦益睆劯砡硎硤硺礰礼神"],["fb80","祥禔福禛竑竧靖竫箞精絈絜綷綠緖繒罇羡羽茁荢荿菇菶葈蒴蕓蕙蕫﨟薰蘒﨡蠇裵訒訷詹誧誾諟諸諶譓譿賰賴贒赶﨣軏﨤逸遧郞都鄕鄧釚釗釞釭釮釤釥鈆鈐鈊鈺鉀鈼鉎鉙鉑鈹鉧銧鉷鉸鋧鋗鋙鋐﨧鋕鋠鋓錥錡鋻﨨錞鋿錝錂鍰鍗鎤鏆鏞鏸鐱鑅鑈閒隆﨩隝隯霳霻靃靍靏靑靕顗顥飯飼餧館馞驎髙"],["fc40","髜魵魲鮏鮱鮻鰀鵰鵫鶴鸙黑"]]')},16412:e=>{"use strict";e.exports=JSON.parse('{"filetypes":[".md",".rmd",".markdown",".txt",".tex",".mdx"],"ignoreDirs":[".+?\\\\.app",".+?\\\\.textbundle"],"import_files":[["Markdown","md","markdown","rmd","mdx"],["DocBook","docbook"],["Microsoft Word","docx","doc"],["EPUB","epub"],["Haddock","haddock","hs"],["Hypertext Markup Language","html","htm"],["LaTeX","tex","latex"],["Muse","muse"],["Open Document Text","odt"],["Outline Processor Markup Language","opml"],["Emacs .org file","org"],["reStructured Text","rst"],["Rich Text Format","rtf"],["txt2tags","t2t"],["TextBundle","textbundle"],["TextPack (Compressed TextBundle)","textpack"],["Textile","textile"],["Wiki Markup","wiki"],["MAN pages (roff)","man"],["MAN pages (ms)","ms"],["FictionBook2","fb2"],["Jupyter Notebook","ipynb"],["Jira Markup","jira"]]}')}},t={};function r(i){var n=t[i];if(void 0!==n)return n.exports;var s=t[i]={id:i,loaded:!1,exports:{}};return e[i].call(s.exports,s,s.exports,r),s.loaded=!0,s.exports}r.n=e=>{var t=e&&e.__esModule?()=>e.default:()=>e;return r.d(t,{a:t}),t},r.d=(e,t)=>{for(var i in t)r.o(t,i)&&!r.o(e,i)&&Object.defineProperty(e,i,{enumerable:!0,get:t[i]})},r.o=(e,t)=>Object.prototype.hasOwnProperty.call(e,t),r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.nmd=e=>(e.paths=[],e.children||(e.children=[]),e),void 0!==r&&(r.ab=__dirname+"/native_modules/");var i=r(27445);module.exports=i})();

I have tried to close everything and reopen it (-m): The first time it crashed directly when trying to show. Then I was back to be open it and crash on exit.

So:
RangeError: Maximum call stack size exceeded

See the attached file:
/usr/lib/zettlr/resources/app.asar/.webpack/main/index.js:2
(()=>{var e={70755:(e,t)=>{"use strict";Object.defineProper...

RangeError: Maximum call stack size exceeded

Please remember, this is not the segfault, this is opening zettlr using "-m", display zettlr, and when I close it, this is printed into the console.

[nathanlesage]

A lot of incomprehensible text (looks somehow like a compiled source code archive?) is printed in the console than:

I noticed that myself, but thought it might be due to some weirdness in webpack, I didn't think it reoccurred in the final builds, that may be a good observation!

---

All in all, I believe something in Electron 30 is really bad at handling windows. I've seen segfault bugs on the Electron repo being reported as an interaction with window opening and closing, tiling managers, and maximizing windows. Let's hope they fix this asap; I may consider releasing a 3.1.1 while reverting back to the previous Electron version if a fix won't appear soon.

[nathanlesage]

I just tried it out on my work computer, and Zettlr works flawlessly.

Things to note:

• It's running Manjaro
• No tiling manager
• Hardware acceleration is on
• I forgot to run Yarn install so it runs on 30.0.1 (will report with 30.0.2), but I don't believe this to be the cause.

Update: It indeed segfaults on 30.0.2, specifically at the window maximization step (so the window draws fine).

[tannenfreund87]

I run Zettlr on KDE (plasma6, x11). It segfaults when maximizing the window, manually stretching it to the screen size works fine. It also completely segfaults on start, if I choose to use the native window decorations. I tried the RPM and the AppImage, both show the same behaviour.

[m1ga]

I have now downgraded Electron to 29.3.2 which, at least on my system, launches fine. I'll immediately schedule a manual nightly build, and request that all of you who have this issue try this one out -- just to see if it still segfaults. If it doesn't, I'll release a hotfix that downgrades Electron to 29.3.2 so that we can all use the app again.

Nightly build works fine!

No crash on startup or resizing the window.

Linux fedora 6.8.8-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 27 17:53:31 UTC 2024 x86_64 GNU/Linux
KDE, Wayland

[w-wagner]

I confirm: When I start Zettlr using the "-m" trick, restore it to not be in fullscreen mode and exit, I can start zettlr in normal mode.
In the moment I try to maximize it, it crashes with a lot of text (propably the same as above) in the console.

RangeError: Maximum call stack size exceeded

btw: The --trace-uncaught... option did not work, changed anything.

Closing the non maximized window still issues the error message about the stack error. It happens when I close the non maximized error. This time adding the nodejs version information.
I attached the output when I close
zettlr_out_not_maximized_closing.txt

And also the crash output, when I maximize the window:
zettlr_out_maximizing.txt

I am going to try the nightly build now

[dustdfg]

Nightly works fine

[McTom234]

Hey @nathanlesage, is there an estimate for the Arch package 3.1.1 release?

[tannenfreund87]

Hey @nathanlesage, is there an estimate for the Arch package 3.1.1 release?

Arch packages are community maintained, you need to ask the package maintainer:
https://archlinux.org/packages/extra/x86_64/zettlr/
Caleb Maclennan, @alerque

Or you just wait, he's quite active, and the upgrade should arrive soon.

[nathanlesage]

I was reluctant to bump the Arch Linux package that involved downgrading ELectron for a bug that I couldn't reproduce

Electron 29 is still in the supporting frame, and tbh I think that it is kind of shitty of the Electron team to push this tight of a timeline onto volunteering FOSS developers anyhow. After this experience I will go back to my usual schedule of keeping one full version distance to Electron main. This is by far not the first instance where the most recent Electron version had serious bugs for people. It's similar to macOS updates: the initial ones are kind of bad, but they get better over time. What I will do, though, is publish new releases more frequently, even if that only means to bump Electron to keep up with supported versions.