Change:
# Hardening , graphene-hardened-malloc # Whether to use graphene-hardened-malloc <del> , useHardenedMalloc ? true </del> <ins> , useHardenedMalloc ? null </ins> # Whether to disable multiprocess support , disableContentSandbox ? false

Discussion:
tor-browser crashes with a segmentation fault immediately after startup Steps to reproduce the behavior: nixpkgs-unstable to avoid 404 download errors: channels: nixpkgs-unstable to tor-browser-bundle-bin with home-manager: tor-browser tor-browser should start without crashing If applicable, add screenshots to help explain your problem. I am using Wayland/Sway with pipewire audio. I have tried without any effect to set MOZENABLEWAYLAND to 1 switch between wayland and x11 for GDK_BACKEND disable pipewire and enable pulseaudio in fish and bash . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
May be related to hardened malloc (it was changed to being on by default in ). Have you tried passing ? You'll have to determine for yourself whether doing so is prudent.
Thanks, tor-browser starts with ! My graphics card is a , it might be related to the "crashing tabs" problem mentioned in
Thanks for the workaround. My graphics card is and I had the same problem.
Another data point: With my graphics chip (also known as Intel HD-Grafik 4400), tor-browser crashes with but works fine with .
Another data point: also seems to happen with my graphics chip , tor-browser crashes, but building with fixes it.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Just bumped into this. Defining from the above discourse thread resolved the issue.
Just a note, if has had a run previously then also seems to work. Steps: 2. close Firefox 4. rejoice This is obviously less than ideal, but it might mean we just have to bootstrap the Firefox profile. Haven't done much investigation edit: Just a follow-up, an initial run without hardening also works ` Close and open normally, then things seem to work.
I no longer have this issue with a clean environment on Wayland
Ditto
Hardened malloc tor-browser still segfaults on my system.
works now on my system (NixOS 22.05)
Can reproduce this on latest NixOS 22.11 using KDE Plasma (Xorg).

The workaround by (launching firefox before tb) works for me, but I think this issue should be re-opened nonetheless as the bug isn't really fixed. <delAt least the latest stable release (22.11) doesn't work so even if this was fixed in unstable (like commented), the fix should be backported, thus another reason to re-open.</delEdit: Nope definitely wasn't fixed in unstable.
I've still got this issue. AMD 5850U, KDE, Wayland
FWIW, someone on Matrix just ran into this and solved it for them.
You're listed as maintainers, should this stay broken or could hardenedmalloc we opt-in rather than "opt-out"? It'd be a non-breaking change for everyone consuming the package with inputs as-is today if switched.
Thank you for the ping. I don't get this issue myself but looks like quite a few people are affected. I've actually looked a bit into the malloc stuff in Firefox a while ago and it seems that providing a different allocator via doesn't even (fully) work because Firefox statically links jemalloc (see ). The only way around this is building Firefox with and Tor Browser's official builds don't do this. I think it would actually be best just to remove the option altogether.
thanks for your engagement!