Tor Browser refuses to start with <jemalloc>: Corrupt redzone 0 bytes after 0x7f0503ede9d0 (size 80), byte=0x0

[adrelanos]

Since Tor Browser 7.0a2 it does no longer start. (Debian stretch based Qubes-Whonix 14)

user@host:~/.tb/tor-browser$ ./start-tor-browser.desktop --debug
Launching './Browser/start-tor-browser --detach --debug'...
Using system Tor process.
<jemalloc>: Corrupt redzone 0 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 1 byte after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 2 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 3 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 4 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 5 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 6 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 7 bytes after 0x7f0503ede9d0 (size 80), byte=0x0
./Browser/start-tor-browser: line 368:  2593 Segmentation fault      TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser" -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null
user@host:~/.tb/tor-browser$ echo $?
139

Something in the system config or environment seems to trigger this. Any idea?

Related:
#10281

[gk]

And this works (worked) with 7.0a1?

[adrelanos]

No.

6.5.1 works for me. Any other versions I should try?

[gk]

Replying to adrelanos:

No.

6.5.1 works for me. Any other versions I should try?

6.5a5 and 6.5a6: ​https://archive.torproject.org/tor-package-archive/torbrowser/

[adrelanos]

• 6.5a5 works for me.
• 6.5a6 jemalloc failure with slightly different output.

./start-tor-browser.desktop --debug
Launching './Browser/start-tor-browser --detach --debug'...
Using system Tor process.
<jemalloc>: Corrupt redzone 0 bytes after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 1 byte after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 2 bytes after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 3 bytes after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 4 bytes after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 5 bytes after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 6 bytes after 0x7fcec06de960 (size 80), byte=0x0
<jemalloc>: Corrupt redzone 7 bytes after 0x7fcec06de960 (size 80), byte=0x0
./Browser/start-tor-browser: line 372:  6757 Segmentation fault      TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser" -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null

[gk]

6.5a6 is the first version that contains our jemalloc hardening. adrelanos: Could you try narrowing the issue down by starting Tor Browser outside Qubes-Whonix the same way you do within Qubes-Whonix? And then if that does not explode just starting it in Qubes without the Whonix component? Does that already explode? Or do you need Whonix to get to that?

[adrelanos]

6.5a6

• Qubes Debian stretch based AppVM: works
• VirtualBox Debian stretch: works
• VirtualBox Whonix Debian stretch based VM: broken
• Qubes-Whonix Debian stretch based AppVM: broken

"Some setting that Whonix changes or package that Whonix does (not) install is triggering this issue." (No recompiled packages.) Any advice on narrow it down more than that?

[gk]

Replying to adrelanos:

6.5a6

• Qubes Debian stretch based AppVM: works
• VirtualBox Debian stretch: works
• VirtualBox Whonix Debian stretch based VM: broken
• Qubes-Whonix Debian stretch based AppVM: broken

"Some setting that Whonix changes or package that Whonix does (not) install is triggering this issue." (No recompiled packages.) Any advice on narrow it down more than that?

Unfortunately, not. We won't ship Tor Browser with jemalloc4 anymore as Mozilla has indicated that they won't use it in the future. Thus, this bug is somewhat moot and I'll close it as WONTFIX. (Might still be interesting to understand why this happens in the first place at all)

[adrelanos]

Replying to gk:

(Might still be interesting to understand why this happens in the first place at all)

Our environment variable XDG_CONFIG_DIRS had too many entries. Details:

​https://phabricator.whonix.org/T651#13878