I just started having problems due to this issue recently on Ubuntu 16.04.4 with libjavascriptcoregtk-4.0-18 version 2.20.1-0ubuntu0.16.04.1. Several Gnome 3.18 applications will crash on startup (including Rhythmbox 3.3, yelp, gnome-control-center, unity-control-center 15.04.0+16.04.20171130-0ubuntu1, zenity, but basically anything that depends on WebKit I guess). I get the following (or similar) error message:
FATAL: Could not allocate gigacage memory with maxAlignment = 34359738368, totalSize = 103079215104.
(Make sure you have not set a virtual memory limit.)
Setting the environment variable GIGACAGE_ENABLED=0 is a good workaround.
I have overcommit_memory = 2, and I prefer to have it that way (short reason: I develop and run various programs for scientific computations, which sometimes need a lot of memory -- in my case, it is clearly preferable to have a memory allocation fail, producing a meaningful error message than having a seemingly random crash later or invoking the OOM killer). Nevertheless, I still use Gnome desktop applications, which depend on WebKit, producing this issue.
My understanding is that the only way to fix this is to use PROT_NONE when allocating address space and later use mprotect() before actually using it. I understand that depending the structure of the code, that could be a lot of work to do for a somewhat specialized use case.
Let me know if I can provide any more info.
Stack trace:
Thread 1 (Thread 0x7ffff7edda80 (LWP 16799)):
#0 0x00007fffeccdb905 in ?? ()
from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#1 0x00007ffff66b4a99 in __pthread_once_slow (once_control=0x7fffecf49008,
init_routine=0x7fffe8aceac0 <__once_proxy>) at pthread_once.c:116
#2 0x00007fffeccdb243 in Gigacage::ensureGigacage() ()
from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#3 0x00007fffecce05a8 in bmalloc::mapToActiveHeapKind(bmalloc::HeapKind) ()
from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#4 0x00007fffeccd9d3e in bmalloc::Cache::allocateSlowCaseNullCache(bmalloc::HeapKind, unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#5 0x00007fffeccbf6f6 in WTF::StringImpl::createFromLiteral(char const*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#6 0x00007fffeccbf781 in WTF::StringImpl::createFromLiteral(char const*) ()
from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#7 0x00007fffecccbc20 in WTF::String::String(WTF::ASCIILiteral) ()
from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#8 0x00007ffff3865a17 in ?? ()
from /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#9 0x00007ffff7de76ba in call_init (l=<optimized out>, argc=argc@entry=1,
argv=argv@entry=0x7fffffffe608, env=env@entry=0x7fffffffe618)
at dl-init.c:72
#10 0x00007ffff7de77cb in call_init (env=0x7fffffffe618, argv=0x7fffffffe608,
argc=1, l=<optimized out>) at dl-init.c:30
#11 _dl_init (main_map=0x7ffff7ffe168, argc=1, argv=0x7fffffffe608,
env=0x7fffffffe618) at dl-init.c:120
#12 0x00007ffff7dd7c6a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#13 0x0000000000000001 in ?? ()
#14 0x00007fffffffe91c in ?? ()
#15 0x0000000000000000 in ?? ()
Hi,
I just started having problems due to this issue recently on Ubuntu 16.04.4 with libjavascriptco regtk-4. 0-18 version 2.20.1- 0ubuntu0. 16.04.1. Several Gnome 3.18 applications will crash on startup (including Rhythmbox 3.3, yelp, gnome-control- center, unity-control- center 15.04.0+ 16.04.20171130- 0ubuntu1, zenity, but basically anything that depends on WebKit I guess). I get the following (or similar) error message:
FATAL: Could not allocate gigacage memory with maxAlignment = 34359738368, totalSize = 103079215104.
(Make sure you have not set a virtual memory limit.)
Setting the environment variable GIGACAGE_ENABLED=0 is a good workaround.
I have overcommit_memory = 2, and I prefer to have it that way (short reason: I develop and run various programs for scientific computations, which sometimes need a lot of memory -- in my case, it is clearly preferable to have a memory allocation fail, producing a meaningful error message than having a seemingly random crash later or invoking the OOM killer). Nevertheless, I still use Gnome desktop applications, which depend on WebKit, producing this issue.
My understanding is that the only way to fix this is to use PROT_NONE when allocating address space and later use mprotect() before actually using it. I understand that depending the structure of the code, that could be a lot of work to do for a somewhat specialized use case.
Let me know if I can provide any more info.
Stack trace:
Thread 1 (Thread 0x7ffff7edda80 (LWP 16799)): x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 0x7fffecf49008, routine= 0x7fffe8aceac0 <__once_proxy>) at pthread_once.c:116 :ensureGigacage () () x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 :mapToActiveHea pKind(bmalloc: :HeapKind) () x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 :Cache: :allocateSlowCa seNullCache( bmalloc: :HeapKind, unsigned long) () x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 ::createFromLit eral(char const*, unsigned int) () from /usr/lib/ x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 ::createFromLit eral(char const*) () x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 :String( WTF::ASCIILiter al) () x86_64- linux-gnu/ libjavascriptco regtk-4. 0.so.18 x86_64- linux-gnu/ libwebkit2gtk- 4.0.so. 37 argv@entry= 0x7fffffffe608, env=env@ entry=0x7ffffff fe618) e618, argv=0x7fffffff e608, 0x7ffff7ffe168, argc=1, argv=0x7fffffff e608, 0x7fffffffe618) at dl-init.c:120 ld-linux- x86-64. so.2
#0 0x00007fffeccdb905 in ?? ()
from /usr/lib/
#1 0x00007ffff66b4a99 in __pthread_once_slow (once_control=
init_
#2 0x00007fffeccdb243 in Gigacage:
from /usr/lib/
#3 0x00007fffecce05a8 in bmalloc:
from /usr/lib/
#4 0x00007fffeccd9d3e in bmalloc:
from /usr/lib/
#5 0x00007fffeccbf6f6 in WTF::StringImpl
#6 0x00007fffeccbf781 in WTF::StringImpl
from /usr/lib/
#7 0x00007fffecccbc20 in WTF::String:
from /usr/lib/
#8 0x00007ffff3865a17 in ?? ()
from /usr/lib/
#9 0x00007ffff7de76ba in call_init (l=<optimized out>, argc=argc@entry=1,
argv=
at dl-init.c:72
#10 0x00007ffff7de77cb in call_init (env=0x7fffffff
argc=1, l=<optimized out>) at dl-init.c:30
#11 _dl_init (main_map=
env=
#12 0x00007ffff7dd7c6a in _dl_start_user () from /lib64/
#13 0x0000000000000001 in ?? ()
#14 0x00007fffffffe91c in ?? ()
#15 0x0000000000000000 in ?? ()