Bug 1564970
| Summary: | [abrt] evolution: Gigacage::<lambda()>::operator()(): evolution killed by SIGSEGV | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yogesh Sharma <yogeshsharma> | ||||||||||||||||||||||||||||
| Component: | webkitgtk4 | Assignee: | Tomas Popela <tpopela> | ||||||||||||||||||||||||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||||
| Version: | 27 | CC: | alexl, caillon+fedoraproject, fweimer, jskarvad, kaiserkarl31, lucilanga, mcatanzaro+wrong-account-do-not-cc, mcrha, rhughes, rstrode, sandmann, tpopela, zlynx | ||||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/ec0d401be6aaf9800d4eb2376b8cc22c90f31d0e | ||||||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:0abd6be6589e247bbfa57d755c4ec7e437138ac8;VARIANT_ID=workstation; | ||||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||||
| Last Closed: | 2018-04-09 08:02:32 UTC | Type: | --- | ||||||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||
|
Description
Yogesh Sharma
2018-04-09 04:32:29 UTC
Created attachment 1419101 [details]
File: backtrace
Created attachment 1419102 [details]
File: cgroup
Created attachment 1419103 [details]
File: core_backtrace
Created attachment 1419104 [details]
File: cpuinfo
Created attachment 1419105 [details]
File: dso_list
Created attachment 1419106 [details]
File: environ
Created attachment 1419107 [details]
File: exploitable
Created attachment 1419108 [details]
File: limits
Created attachment 1419109 [details]
File: maps
Created attachment 1419110 [details]
File: mountinfo
Created attachment 1419111 [details]
File: open_fds
Created attachment 1419112 [details]
File: proc_pid_status
Created attachment 1419113 [details]
File: var_log_messages
Thanks for a bug report. This is due to update of webkitgtk4 package to its 2.20.0 release. See more information here, please: https://bugs.webkit.org/show_bug.cgi?id=183329#c22 The bug contains some information how to work with this new requirement (eventually search for GIGACAGE_ENABLE in there). We can change it so that Gigacage gets disabled instead of crashing, but that's a very important security feature and I'm kinda hesitant to just silently disable it. I guess we can decide based on how many crash reports like this we get. I had to change vm.overcommit_memory=0 for evolution to work, I had it set to 2. Similar issue I had with gnome-control-center for that export GIGACAGE_ENABLED=0 worked. (In reply to Yogesh Sharma from comment #16) > Similar issue I had with gnome-control-center for that export > GIGACAGE_ENABLED=0 worked. You could also set that globally if you want to keep overcommit disabled. *** Bug 1565667 has been marked as a duplicate of this bug. *** The above duplicate is from Fedora 26, just that you know. (In reply to Michael Catanzaro from comment #15) > We can change it so that Gigacage gets disabled instead of crashing Crashing is always bad. The code should handle errors gracefully, where the crash is far from graceful handling. It's called 'robust code', right? Anyway, in case of Evolution itself there's no such issue as with Epiphany or any real browser. Yes, WebKitGTK+ is used with OAuth2 authentication, though even that is supposed to access hard-coded known addresses, not some random pages, and if the user does overwrite the domain in /etc/hosts or such, then it's his/her responsibility anyway. (In reply to Michael Catanzaro from comment #15) > We can change it so that Gigacage gets disabled instead of crashing, but > that's a very important security feature and I'm kinda hesitant to just > silently disable it. I guess we can decide based on how many crash reports > like this we get. See bug 1570021 comment 0: You should call mmap with PROT_NONE first, and then carve out actually allocations from the reserved area using mprotect. *** Bug 1570341 has been marked as a duplicate of this bug. *** (In reply to Michael Catanzaro from comment #15) > We can change it so that Gigacage gets disabled instead of crashing, but > that's a very important security feature and I'm kinda hesitant to just > silently disable it. I guess we can decide based on how many crash reports > like this we get. I've just got a build crash (SIGSEGV during build) of evolution-data-server in an aarch64 mock and it was damn hard to find out it crashed due to the Gigacage, because it did that during GObject introspection code generation. I do not want to add the `export` into each single package .spec file which uses WebKitGTK+ and all those which use those packages, just to make sure the build break will not happen again. I can write a similar/same comment in the upstream bug report (or create a new one there), but I hope this gets a bit more attention here, rather than there. I also do not know how much you'd consider it a downstream issue though. (In reply to Milan Crha from comment #22) > I can write a similar/same comment in the upstream bug report (or create a > new one there), but I hope this gets a bit more attention here, rather than > there. I also do not know how much you'd consider it a downstream issue > though. It's upstream issue and upstream is aware of it. Please don't create a new bug report - it's handled in https://bugs.webkit.org/show_bug.cgi?id=183329 (In reply to Tomas Popela from comment #23) > It's upstream issue and upstream is aware of it. Please don't create a new > bug report - it's handled in https://bugs.webkit.org/show_bug.cgi?id=183329 Okay, will not do. Thanks for the pointer. I opened this: https://bugs.webkit.org/show_bug.cgi?id=185762 which is related, but not the same thing. (In reply to Milan Crha from comment #22) > I've just got a build crash (SIGSEGV during build) of evolution-data-server > in an aarch64 mock and it was damn hard to find out it crashed due to the > Gigacage, because it did that during GObject introspection code generation. Do we known why it crashed? It shouldn't crash unless the builder has disabled VM overcommit or set a virtual memory ulimit. Certainly, you shouldn't have to disable gigacage to use gobject-introspection. (In reply to Michael Catanzaro from comment #25) > (In reply to Milan Crha from comment #22) > > I've just got a build crash (SIGSEGV during build) of evolution-data-server > > in an aarch64 mock and it was damn hard to find out it crashed due to the > > Gigacage, because it did that during GObject introspection code generation. > > Do we known why it crashed? It shouldn't crash unless the builder has > disabled VM overcommit or set a virtual memory ulimit. BMALLOC_NORESERVE appears to be defined as MAP_NORESERVE, which turns off memory overcommit in vm.overcommit_memory=0 mode. The mmap call will always succeed. Out of memory is reported via SIGSEGV on write instead. Then surely the OOM condition is not WebKit's fault? (In reply to Michael Catanzaro from comment #27) > Then surely the OOM condition is not WebKit's fault? Could be. Also the Gigacage allocation on aarch64 could fail - the code is ready for that[0] and [1]. So it looks like it's a different bug. [0] - https://trac.webkit.org/browser/webkit/trunk/Source/bmalloc/bmalloc/Gigacage.h#L39 [1] - https://trac.webkit.org/browser/webkit/trunk/Source/bmalloc/bmalloc/Gigacage.cpp#L151 Below is the only thing I see in the build log. I tried to disable the gigacage in the .spec file and it did help, thus it's it, from my point of view. (In reply to Michael Catanzaro from comment #25) > Certainly, you shouldn't have to disable gigacage to use > gobject-introspection. I agree. There's this one for it: https://bugs.webkit.org/show_bug.cgi?id=185762 ------------------------------------------------------------------------------ In the build log: Command '['/builddir/build/BUILD/evolution-data-server-3.28.1/_build/src/libedataserver/tmp-introspect4eikde20/EDataServer-1.2', '--introspect-dump=/builddir/build/BUILD/evolution-data-server-3.28.1/_build/src/libedataserver/tmp-introspect4eikde20/functions.txt,/builddir/build/BUILD/evolution-data-server-3.28.1/_build/src/libedataserver/tmp-introspect4eikde20/dump.xml']' died with <Signals.SIGSEGV: 11>. make[2]: Leaving directory '/builddir/build/BUILD/evolution-data-server-3.28.1/_build' make[2]: *** [src/libedataserver/CMakeFiles/gir-typelibs-EDataServer_1_2_gir.dir/build.make:236: src/libedataserver/EDataServer-1.2.gir] Error 1 make[1]: *** [CMakeFiles/Makefile2:5470: src/libedataserver/CMakeFiles/gir-typelibs-EDataServer_1_2_gir.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... *** Bug 1569478 has been marked as a duplicate of this bug. *** |