Still happening with 7.0a4

We won't ship Tor Browser with jemalloc4 anymore

https://trac.torproject.org/projects/tor/ticket/21804#comment:8

Uh. Does that mean they're taking it out? In the next alpha, and we can close this?

My WS TBB updated itself to 7.0.1 and it is running fine.

No, we must understand which part exactly of Whonix is triggering such a strange bug.

The main problem at the level of software errors is that the "simplification of memory allocation" undertaken by the developers of the browser in version 6.56a seems to give the error of the memory leaks during the integrity check procedure on the bug tracker, they will indicate "memory hardening" - as additional memory protection mechanisms Including interference with environment variables LD_PRELOAD and LD_LIBRARY_PATH)

Jemalloc allocates memory not as standard C-based malloc (or based on bust-based) - the standard distributed memory scheme assumes the usual allocation of pages and the display of process images in them, almost as well as in windows.
Jemalloc makes a break from the memory of the areas called "arenas". This is done in order to collect all the libraries at different times in order to avoid any errors in the flow, for example, the threads that execute plug-ins into memory, for example, the rendering engine.

When I collected the debugging symbols and turned off the code optimization for versions 7.04a (firefox 51.1.1), it turned out that error messages in the redzone integrity begin to flow in the arenas validation procedure.
In this procedure, only messages, segfolt, which makes the debugger hangs later and is called from the process of infecting the SIGENV kernel, to avoid code variants in the wrong memory.

I have a very long time in the history of the bugtracker Firefox and when they solved the problem with jemalloc 3 (now used in 4 countries of the world) - there there is several times a similar situation where on different platforms the calculation of allocated memory ends with an error due to different values ​​of some constants for Different platforms. And then they were manually distributed by hand, and then most likely forgot about it with the release of the new version. In the jamalloc bugtracker, everything is very sad, and so they decided to remove it from FireFox. And of course TorBrowser project immediately followed suit.
That's when they closed this bug with a mark of WONTFIX.

I went the other way and noticed that the validation of FireFox itself is wrong, and because of this it falls with an error. But it's ok to validate the redzone validation in jemalloc in the FireFox assembly options and everything works. But of course all the advantages of "memory hardening" disappear

I also assumed that the error consists of the problems associated with the failure of redzone in jemalloc - then this is a gross error of the concrete version of jemalloc, which can not be returned back. New versions of Firefox are no longer compatible with the old jemalloc3.

Then I started to rebuild myself Whonix, it was possible to compile on Travis. There were a lot of mistakes that had to be eliminated and wasted time for understanding in the availability of undocumented details. As a result, I collected incorrectly, as a result of which the variable XDG_CONFIG_DIRS remained almost empty. The distribution remained almost in the state of pure debian. In this state, I started the browser and it worked.
I compared the environment of Whonix and the surroundings of what I had collected. I came to the conclusion that the difference is only in this variable. Checked it - it turned out that this is true.
The environment variable XDG_CONFIG_DIRS to different additional directories of the Whonix configuration files.
I started to produce a lot of testing, which wasted my time. As a result, I came to the conclusion that 7 kinds of any catalogs, even nonexistent, do not affect the launch of the browser, adding the eighth directory results in a memory leak.
Business in the very number.
It turned out that this is a common software problem in C - going beyond the boundaries of variables / arrays.

It does not affect TorBrowser itself. This affects the processing of the jemalloc4 function variables.
Because if you disable jemalloc4 during compilation - TorBrowser is compiled without it and starts.
But the very idea is to protect the memory of the browser using jemalloc4.

This problem is also relevant on pure Debian. If there are more than 7 directories in the variable XDG_CONFIG_DIRS, then the browser will fall with this error, because jemalloc can not process it.

You can check it as follows.

Open terminal, write
Echo $ XDG_CONFIG_DIRS
The current value is displayed - a list of folders is displayed, the divided symbol :.
Next we introduce
XDG_CONFIG_DIRS = /etc/XDG
Resets the variable to the default value
Download the problem version of TorBrowser
Wget https://archive.torproject.org/tor-package-archive/torbrowser/7.0a2/tor-browser-linux64-7.0a2_en-US.tar.xz
Unpack it
Tar xf tor-browser-linux64-7.0a2_en-US.tar.xz
Go to the browser directory
Cd tor-browser_en-US
Launch
./start-tor-browser.desktop --debug

The browser should start.

Next, we set 7 directories, the values ​​can be randomized
XDG_CONFIG_DIRS = /etc/XDG:/etc/XDG:/etc/XDG:/etc/XDG:/etc/XDG:/etc/XDG:/etc/ XDG
Launch
./start-tor-browser.desktop --debug

Again I have to start
Next, we set 8 directories
XDG_CONFIG_DIRS = /etc/xdg:/etc/xdg:/etc/xdg:/etc/xdg:/etc/xdg:/etc/xdg:/etc/xdg:/etc/xdg
Launch
./start-tor-browser.desktop --debug

We get the same error as in the case with the usual value for Whonix 14.

Distressed versions have all been removed from the repositories, make version 7.5 without these problems. , So this problem version can not be used.

Now with the new versions of jemalloc 4 - this problem is no longer relevant.

Thanks @matvey. It's nice to see this resolved.