Bug 1074093

Summary: Webkitgtk3 crashes on PPC64/AArch64 due to mprotect() on address not aligned to the page size
Product: [Fedora] Fedora Reporter: Gustavo Luiz Duarte <gustavold>
Component: webkitgtk3Assignee: Matthias Clasen <mclasen>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 22CC: gustavold, hannsj_uhl, kalevlember, mclasen, normand, tpopela, yselkowi
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 19:00:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1051573, 1113345, 1113347    
Attachments:
Description Flags
commitSize_to_be_pageSize.patch none

Description Gustavo Luiz Duarte 2014-03-07 22:22:48 UTC
Description of problem:
I notice this issue trying to build 'seed' on rawhide. Here is the error message during seed build:

Making all in readline
make[4]: Entering directory `/builddir/fedora/seed/master/seed-3.8.1/doc/modules/readline'
../../../src/seed ../../../doc/modules/make-functions.js ../../../doc/modules/readline/readline.js > ../../../doc/modules/readline/readline-funcs.xml
1   0x3fff92ed6f5c /lib64/libjavascriptcoregtk-3.0.so.0(WTFCrash-0x14038c) [0x3fff92ed6f5c]
2   0x3fff92ef99c8 /lib64/libjavascriptcoregtk-3.0.so.0(_ZN3WTF11OSAllocator6commitEPvmbb-0x11e6a0) [0x3fff92ef99c8]
3   0x3fff92c40120 /lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC7JSStack12growSlowCaseEPNS_8RegisterE-0x3c8b78) [0x3fff92c40120]
4   0x3fff92c3de68 /lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC7JSStack10entryCheckEPNS_9CodeBlockEi-0x3cab20) [0x3fff92c3de68]
5   0x3fff92c3c5d0 /lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC11Interpreter7executeEPNS_17ProgramExecutableEPNS_9ExecStateEPNS_8JSObjectE-0x3cc638) [0x3fff92c3c5d0]
6   0x3fff92d40a28 /lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC8evaluateEPNS_9ExecStateERKNS_10SourceCodeENS_7JSValueEPS5_-0x2cda90) [0x3fff92d40a28]
7   0x3fff92b2ec30 /lib64/libjavascriptcoregtk-3.0.so.0(JSEvaluateScript-0x4d1aa8) [0x3fff92b2ec30]
8   0x3fff9333128c /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_simple_evaluate-0x2f90c) [0x3fff9333128c]
9   0x3fff93336c6c /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init_constrained_with_context_and_group-0x2a3ec) [0x3fff93336c6c]
10  0x3fff93336f04 /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init_with_context_and_group-0x2a164) [0x3fff93336f04]
11  0x3fff93337028 /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init_with_context_group-0x2a050) [0x3fff93337028]
12  0x3fff933370a0 /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/libseed-gtk3.so.0(seed_init-0x29fe8) [0x3fff933370a0]
13  0x100010dc /builddir/fedora/seed/master/seed-3.8.1/src/.libs/lt-seed() [0x100010dc]
14  0x3fff931166ec /lib64/libc.so.6(+0x466ec) [0x3fff931166ec]
15  0x3fff931168f4 /lib64/libc.so.6(__libc_start_main-0x1aaf0c) [0x3fff931168f4]
/bin/sh: line 1:  4677 Segmentation fault      ../../../src/seed ../../../doc/modules/make-functions.js ../../../doc/modules/readline/readline.js > ../../../doc/modules/readline/readline-funcs.xml


And here is a backtrace from gdb:

(gdb) bt  
#0  0x00003fffb7916f70 in WTFCrash () at Source/WTF/wtf/Assertions.cpp:333
#1  0x00003fffb79399c8 in WTF::OSAllocator::commit (address=0x3fffb39cc000, bytes=16384, writable=<optimized out>, executable=<optimized out>)
    at Source/WTF/wtf/OSAllocatorPosix.cpp:134
#2  0x00003fffb7680120 in commit (this=0x3fffb44cef38, this=0x3fffb44cef38, this=0x3fffb44cef38, size=<optimized out>, start=<optimized out>)
    at Source/WTF/wtf/PageReservation.h:85
#3  JSC::JSStack::growSlowCase (this=0x3fffb44cef18, newEnd=0x3fffb39cff70) at Source/JavaScriptCore/interpreter/JSStack.cpp:89
#4  0x00003fffb767de68 in grow (newEnd=<optimized out>, this=0x3fffb44cef18) at Source/JavaScriptCore/interpreter/JSStackInlines.h:180
#5  JSC::JSStack::entryCheck (this=0x3fffb44cef18, codeBlock=<optimized out>, argsCount=<optimized out>)
    at Source/JavaScriptCore/interpreter/JSStackInlines.h:77
#6  0x00003fffb767c5d0 in JSC::Interpreter::execute (this=0x3fffb44cef00, program=0x3fffb34eff70, callFrame=0x3fffb359f9b0, thisObj=0x3fffb357fbb0)
    at Source/JavaScriptCore/interpreter/Interpreter.cpp:891
#7  0x00003fffb7780a28 in JSC::evaluate (exec=0x3fffb359f9b0, source=..., thisValue=..., returnedException=0x3fffffffed90)
    at Source/JavaScriptCore/runtime/Completion.cpp:82
#8  0x00003fffb756ec30 in JSEvaluateScript (ctx=<optimized out>, script=0x3fffb44b3258, thisObject=0x0, sourceURL=<optimized out>, 
    startingLineNumber=<optimized out>, exception=0x0) at Source/JavaScriptCore/API/JSBase.cpp:63
#9  0x00003fffb7d7128c in seed_simple_evaluate (ctx=0x3fffb359f9b0, source=<optimized out>, exception=0x0) at seed-api.c:305
#10 0x00003fffb7d76c6c in seed_init_constrained_with_context_and_group (argc=<optimized out>, argv=<optimized out>, context=0x3fffb359f9b0, 
    group=0x3fffb44b4000) at seed-engine.c:1734
#11 0x00003fffb7d76f04 in seed_init_with_context_and_group (argc=<optimized out>, argv=<optimized out>, context=<optimized out>, group=<optimized out>)
    at seed-engine.c:1792
#12 0x00003fffb7d77028 in seed_init_with_context_group (argc=0x3ffffffff200, argv=0x3ffffffff198, group=0x3fffb44b4000) at seed-engine.c:1830
#13 0x00003fffb7d770a0 in seed_init (argc=0x3ffffffff200, argv=<optimized out>) at seed-engine.c:1852
#14 0x00000000100010dc in main (argc=1, argv=<error reading variable: value has been optimized out>) at main.c:152


As you can see, the 'address' parameter on frame #1, which is passed to mprotect(), is not aligned to 64k (the page size for Fedora kernel on PPC64). The mprotect() syscall requires the address to be aligned to the kernel page size. A quick look at the code points to:

./Source/JavaScriptCore/interpreter/JSStack.h:76: static const size_t commitSize = 16 * 1024;


Would it be feasible to use 64k commitSize? Or maybe decouple the commitSize logic from the kernel page size?

Either way, please don't try to predict the kernel page size on build time. PPC64 (and other architectures) support multiple page sizes, so you can only rely on the the page size reported by the kernel on runtime. You can get it by calling 'sysconf(_SC_PAGESIZE)'.


Version-Release number of selected component (if applicable):
webkitgtk3-2.3.90-3.fc21.ppc64

How reproducible:
Always.

Steps to Reproduce:
1. yum install seed
2. seed
3.

Actual results:
See crash above.

Expected results:
Seed's prompt.

Additional info:

Comment 1 Gustavo Luiz Duarte 2014-03-10 14:47:28 UTC
I tried changing commitSize to 64k and I got another segfault, though it might be a different, unrelated, issue. Here is the stack trace using commitSize as 64k:

#0  JSC::LLInt::CLoop::execute (callFrame=0x3fffb39cff98, entryOpcode=0x3fffb44f0d28, isInitializationPass=false)
    at DerivedSources/JavaScriptCore/LLIntAssembly.h:2283
#1  0x00003fffb7692c94 in executeJS (executableAddress=0x3fffb7693510 <JSC::LLInt::CLoop::execute(JSC::ExecState*, void*, bool)+944>, 
    newCallFrame=<optimized out>) at Source/JavaScriptCore/llint/LLIntThunks.cpp:132
#2  doCallToJavaScript<JSC::executeJS> (protoCallFrame=0x3fffffffe308, 
    executableAddress=0x3fffb7693510 <JSC::LLInt::CLoop::execute(JSC::ExecState*, void*, bool)+944>) at Source/JavaScriptCore/llint/LLIntThunks.cpp:122
#3  JSC::callToJavaScript (executableAddress=0x3fffb7693510 <JSC::LLInt::CLoop::execute(JSC::ExecState*, void*, bool)+944>, protoCallFrame=0x3fffffffe308)
    at Source/JavaScriptCore/llint/LLIntThunks.cpp:137
#4  0x00003fffb7681dec in JSC::JITCode::execute (this=<optimized out>, vm=0x3fffb44b4000, protoCallFrame=0x3fffffffe308, topOfStack=0x3fffb39cfff8)
    at Source/JavaScriptCore/jit/JITCode.cpp:48
#5  0x00003fffb767c6ac in JSC::Interpreter::execute (this=0x3fffb44cef00, program=0x3fffb34eff70, callFrame=0x3fffb359f9b0, thisObj=<optimized out>)
    at Source/JavaScriptCore/interpreter/Interpreter.cpp:906
#6  0x00003fffb7780a48 in JSC::evaluate (exec=0x3fffb359f9b0, source=..., thisValue=..., returnedException=0x3fffffffee00)
    at Source/JavaScriptCore/runtime/Completion.cpp:82
#7  0x00003fffb756ec30 in JSEvaluateScript (ctx=<optimized out>, script=0x3fffb44b3258, thisObject=0x0, sourceURL=<optimized out>, 
    startingLineNumber=<optimized out>, exception=0x0) at Source/JavaScriptCore/API/JSBase.cpp:63
#8  0x00003fffb7d7128c in .seed_simple_evaluate () from /lib64/libseed-gtk3.so.0
#9  0x00003fffb7d76c6c in .seed_init_constrained_with_context_and_group () from /lib64/libseed-gtk3.so.0
#10 0x00003fffb7d76f04 in .seed_init_with_context_and_group () from /lib64/libseed-gtk3.so.0
#11 0x00003fffb7d77028 in .seed_init_with_context_group () from /lib64/libseed-gtk3.so.0
#12 0x00003fffb7d770a0 in .seed_init () from /lib64/libseed-gtk3.so.0
#13 0x000000001000109c in 0000003a.plt_call.g_option_group_add_entries+0 ()
#14 0x00003fffb7b566ec in .generic_start_main.isra () from /lib64/libc.so.6
#15 0x00003fffb7b568f4 in .__libc_start_main () from /lib64/libc.so.6
#16 0x0000000000000000 in ?? ()

Comment 2 Michel Normand 2014-03-13 17:07:32 UTC
Created attachment 874079 [details]
commitSize_to_be_pageSize.patch

This patch avoid the Crash reported as the initial description.
But do not solve the segfault reported in Comment 1

Comment 3 Tomas Popela 2014-04-10 13:04:33 UTC
Just a note there before I will try to upstream it..

diff --git a/Source/JavaScriptCore/heap/CopiedBlock.h b/Source/JavaScriptCore/heap/CopiedBlock.h
index 4685e23..c5da610 100644
--- a/Source/JavaScriptCore/heap/CopiedBlock.h
+++ b/Source/JavaScriptCore/heap/CopiedBlock.h
@@ -81,7 +81,7 @@ public:
     size_t size();
     size_t capacity();
 
-    static const size_t blockSize = 32 * KB;
+    static const size_t blockSize = 64 * KB;
 
     bool hasWorkList();
     CopyWorkList& workList();

Comment 4 Yaakov Selkowitz 2014-06-25 21:27:59 UTC
This also affects aarch64 and the ppc64_align.patch currently in rawhide appears to fix this.

Comment 5 Jaroslav Reznik 2015-03-03 15:33:15 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 6 Fedora End Of Life 2016-07-19 19:00:51 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.