Bug#894376: gnome-control-center crash FATAL: Could not allocate gigacage memory
grandtoubab at msn.com
Sat Jun 16 08:22:01 BST 2018
Here is today status on my Debian 10 Buster
guy at debian:~$ uname --all
Linux debian 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux
guy at debian:~$ cat /etc/environment
guy at debian:~$
guy at debian:~$ apt policy webkit2gtk*
Installé : 2.20.3-1
Candidat : 2.20.3-1
Table de version :
1 http://deb.debian.org/debian experimental/main amd64 Packages
*** 2.20.3-1 500
500 http://deb.debian.org/debian buster/main amd64 Packages
guy at debian:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 14332
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14332
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
guy at debian:~$ env | grep GIG
guy at debian:~$ gnome-control-center
guy at debian:~$
So now gnome-control-center open and close with no errors
Note I had to install webkit2gtk-driver which is the only package referenced with the name webkit2gtk and was not previously intalled on my regular Debian.
De : Jeremy Bicha <jbicha at debian.org>
Envoyé : samedi 16 juin 2018 03:11
À : Andres Freund
Cc : GT; 894376 at bugs.debian.org; webkit2gtk at packages.debian.org
Objet : Re: Bug#894376: gnome-control-center crash FATAL: Could not allocate gigacage memory
Please try again after installing all updates and then log out and log
back in. In particular, you want webkit2gtk 2.20.3-1 which was pushed
to Debian Testing yesterday. The new version should still run even if
you limit memory overcommitting.
I am CCing the webkit2gtk developer in case we want to adjust the
Debian NEWS entry. (Wording improvement suggestions appreciated.) I
talked to Berto about removing the Debian NEWS entry but he wants to
keep it to warn users that a useful security feature will be disabled
if they have memory limits enabled.
You might want to try limiting memory only for the specific
troublesome apps instead of for the entire session.
On Fri, Jun 15, 2018 at 5:04 PM, Andres Freund <andres at anarazel.de> wrote:
> On 2018-03-29 11:04:58 -0400, Jeremy Bicha wrote:
>> On Thu, Mar 29, 2018 at 10:52 AM, GT <grandtoubab at msn.com> wrote:
>> > FATAL: Could not allocate gigacage memory with maxAlignment = 34359738368,
>> Please see the recent note at
> That link is dead. A local copy says:
> webkit2gtk (2.20.0-2) unstable; urgency=medium
> webkit2gtk 2.20.0 contains a security feature named Gigacage that
> requires a virtual memory region of several gigabytes and is used for
> variable-length random-access allocations.
> One consequence of this is that webkit-based applications may not run if
> their maximum virtual memory size is restricted (e.g. using ulimit -v).
> If it's not possible to remove the VM size limits the Gigacage can be
> disabled by setting the environment variable GIGACAGE_ENABLED=no. Keep
> in mind that you will be making your system less secure by doing this.
> -- Alberto Garcia <berto at igalia.com> Wed, 21 Mar 2018 14:14:44 +0200
> Which seems not correct. My system does *NOT* set ulimit -v:
> andres at alap4:~$ ulimit -v
> andres at alap4:~$ gnome-control-center
> FATAL: Could not allocate gigacage memory with maxAlignment = 34359738368, totalSize = 120259084288.
> (Make sure you have not set a virtual memory limit.)
> Segmentation fault
> I suspect this is because the system has strict overcommit enabled.
> That's a *MUCH* more reasonable thing to configure than ulimit -v, and
> is very painful to avoid if you work with memory intensive applications
> (which without it constantly can trigger the OOM killer, rather than the
> culprit getting allocation failures).
> At the very least you should update that note to also refer to strict
> overcommit. But really, that's a pretty crazy restriction.
> Also, it's fairly indefensible to error out with SIGSEGV. The error
> message is ok enough, but that doesn't at all explain the SIGSEGV.
> Andres Freund
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pkg-webkit-maintainers