Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1074093 - Webkitgtk3 crashes on PPC64/AArch64 due to mprotect() on address not aligned to the page size
Summary: Webkitgtk3 crashes on PPC64/AArch64 due to mprotect() on address not aligned ...
Alias: None
Product: Fedora
Classification: Fedora
Component: webkitgtk3
Version: 22
Hardware: ppc64
OS: Linux
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F-ExcludeArch-ppc64le, PPC64LETracker 1113345 1113347
TreeView+ depends on / blocked
Reported: 2014-03-07 22:22 UTC by Gustavo Luiz Duarte
Modified: 2016-07-19 19:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-07-19 19:00:51 UTC

Attachments (Terms of Use)
commitSize_to_be_pageSize.patch (deleted)
2014-03-13 17:07 UTC, Michel Normand
no flags Details | Diff

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/ [0x3fff92ed6f5c]
2   0x3fff92ef99c8 /lib64/ [0x3fff92ef99c8]
3   0x3fff92c40120 /lib64/ [0x3fff92c40120]
4   0x3fff92c3de68 /lib64/ [0x3fff92c3de68]
5   0x3fff92c3c5d0 /lib64/ [0x3fff92c3c5d0]
6   0x3fff92d40a28 /lib64/ [0x3fff92d40a28]
7   0x3fff92b2ec30 /lib64/ [0x3fff92b2ec30]
8   0x3fff9333128c /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/ [0x3fff9333128c]
9   0x3fff93336c6c /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/ [0x3fff93336c6c]
10  0x3fff93336f04 /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/ [0x3fff93336f04]
11  0x3fff93337028 /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/ [0x3fff93337028]
12  0x3fff933370a0 /builddir/fedora/seed/master/seed-3.8.1/libseed/.libs/ [0x3fff933370a0]
13  0x100010dc /builddir/fedora/seed/master/seed-3.8.1/src/.libs/lt-seed() [0x100010dc]
14  0x3fff931166ec /lib64/ [0x3fff931166ec]
15  0x3fff931168f4 /lib64/ [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):

How reproducible:

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

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/
#9  0x00003fffb7d76c6c in .seed_init_constrained_with_context_and_group () from /lib64/
#10 0x00003fffb7d76f04 in .seed_init_with_context_and_group () from /lib64/
#11 0x00003fffb7d77028 in .seed_init_with_context_group () from /lib64/
#12 0x00003fffb7d770a0 in .seed_init () from /lib64/
#13 0x000000001000109c in 0000003a.plt_call.g_option_group_add_entries+0 ()
#14 0x00003fffb7b566ec in .generic_start_main.isra () from /lib64/
#15 0x00003fffb7b568f4 in .__libc_start_main () from /lib64/
#16 0x0000000000000000 in ?? ()

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

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:

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

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

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