Description of problem: Emacs crashes if started with overcommit disabled. Version-Release number of selected component (if applicable): emacs-25.3-3.fc27.x86_64 How reproducible: Always Steps to Reproduce: 1. sysctl -w vm.overcommit_memory=2 2. emacs 3. Actual results: FATAL: Could not allocate gigacage memory with maxAlignment = 34359738368, totalSize = 120259084288. (Make sure you have not set a virtual memory limit.) Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen]) Expected results: No crash, emacs started Additional info: This is regression, because it always worked without overcommit. The machine has 8GB of physical RAM, so I wonder why it is not enough for the emacs.
Maybe dupe of bug 1564970, workaround: $ GIGACAGE_ENABLED=0 emacs
Hmm, it really seems like webkit, why emacs links with webkit?
I cannot reproduce this with the same version. But, I have a custom kernel (4.14.29). Could you please try with a different kernel, plus run "emacs -Q" instead of "emacs"? And yes, it actually looks like a duplicate of the webkit bug, since emacs is linked against webkit. I could also try to create a testing package with the webkit disabled to see if it helps.
It was requested as a feature. I believe it was in bug 1329801.
Maybe you have different version of webkit? I have: webkitgtk4-2.20.1-1.fc27.x86_64 My kernel is stock downstream: 4.15.17-300.fc27.x86_64 We reproduced the problem on two different machines (one with 12 GB of RAM and another with 8 GB of RAM).
$ emacs -Q FATAL: Could not allocate gigacage memory with maxAlignment = 34359738368, totalSize = 120259084288. (Make sure you have not set a virtual memory limit.) Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])
(In reply to Jaroslav Škarvada from comment #5) > Maybe you have different version of webkit? I have: > webkitgtk4-2.20.1-1.fc27.x86_64 Yes, that's it. I have webkitgtk4-2.18.6-1.fc27.x86_64.
*** Bug 1570021 has been marked as a duplicate of this bug. ***
Changing component accordingly. I know that bug 1564970 was closed as UPSTREAM with a workaround provided, but I don't consider it a fix. This should not crash when I forget to set some random environment variable.
(In reply to Jan Synacek from comment #9) > Changing component accordingly. > > I know that bug 1564970 was closed as UPSTREAM with a workaround provided, > but I don't consider it a fix. This should not crash when I forget to set > some random environment variable. In 2.20.3 the gigacage will just disable itself when allocation fails. It's not great since that means several major security features will disappear, but the alternative is crashing and better than that I guess? *** This bug has been marked as a duplicate of bug 1564970 ***