Bug 1569478 - Emacs crashes when started with vm.overcommit_memory = 2
Summary: Emacs crashes when started with vm.overcommit_memory = 2
Keywords:
Status: CLOSED DUPLICATE of bug 1564970
Alias: None
Product: Fedora
Classification: Fedora
Component: webkitgtk4
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Popela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1570021 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-19 11:14 UTC by Jaroslav Škarvada
Modified: 2018-06-08 02:48 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-08 02:48:21 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1564970 0 unspecified CLOSED [abrt] evolution: Gigacage::<lambda()>::operator()(): evolution killed by SIGSEGV 2021-02-22 00:41:40 UTC

Internal Links: 1564970

Description Jaroslav Škarvada 2018-04-19 11:14:11 UTC
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.

Comment 1 Jaroslav Škarvada 2018-04-19 11:21:58 UTC
Maybe dupe of bug 1564970, workaround:

$ GIGACAGE_ENABLED=0 emacs

Comment 2 Jaroslav Škarvada 2018-04-19 11:26:22 UTC
Hmm, it really seems like webkit, why emacs links with webkit?

Comment 3 Jan Synacek 2018-04-19 11:30:09 UTC
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.

Comment 4 Jan Synacek 2018-04-19 11:32:16 UTC
It was requested as a feature. I believe it was in bug 1329801.

Comment 5 Jaroslav Škarvada 2018-04-19 11:35:58 UTC
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).

Comment 6 Jaroslav Škarvada 2018-04-19 11:37:15 UTC
$ 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])

Comment 7 Jan Synacek 2018-04-19 11:38:05 UTC
(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.

Comment 8 Florian Weimer 2018-04-23 07:19:47 UTC
*** Bug 1570021 has been marked as a duplicate of this bug. ***

Comment 9 Jan Synacek 2018-04-23 08:22:59 UTC
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.

Comment 10 Michael Catanzaro 2018-06-08 02:48:21 UTC
(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 ***


Note You need to log in before you can comment on or make changes to this bug.