[Webkit-unassigned] [Bug 209236] REGRESSION(r249808): [GTK] Crash in JSC Config::permanentlyFreeze() on architecture ppc64el

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 19 11:15:31 PDT 2020


https://bugs.webkit.org/show_bug.cgi?id=209236

--- Comment #34 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Michael Catanzaro from comment #28)
> The best solution is to get page size at runtime using
> sysconf(_SC_PAGESIZE), but it looks like the code really wants a
> compile-time solution. So maybe just hardcode 64 KB for these CPUs and for
> CPU(UNKNOWN)? Ideally we would share the value with MarkedBlock.h? clopez,
> what do you think?
> 


(In reply to Tomas Popela from comment #24)
> 
> s390x, ppc64(le) in RHEL and Fedora use 64 KB page size
> aarch64 on RHEL uses 64 KB and on Fedora 4 KB page size


I wonder about doing something like the patch below to avoid future problems in cases where we can't predict the page size.


diff --git a/Source/JavaScriptCore/runtime/JSCConfig.cpp b/Source/JavaScriptCore/runtime/JSCConfig.cpp
index 79cc2b67ba9..b85393e1def 100644
--- a/Source/JavaScriptCore/runtime/JSCConfig.cpp
+++ b/Source/JavaScriptCore/runtime/JSCConfig.cpp
@@ -33,6 +33,7 @@
 #include <mach/mach.h>
 #elif OS(LINUX)
 #include <sys/mman.h>
+#include <unistd.h>
 #endif

 namespace JSC {
@@ -70,7 +71,10 @@ void Config::permanentlyFreeze()
     // There's no going back now!
     result = vm_protect(mach_task_self(), reinterpret_cast<vm_address_t>(&g_jscConfig), ConfigSizeToProtect, DisallowPermissionChangesAfterThis, VM_PROT_READ);
 #elif OS(LINUX)
-    result = mprotect(&g_jscConfig, ConfigSizeToProtect, PROT_READ);
+    // Some architectures on Linux may have non-default page size.
+    // In that cases, avoid the crash in the RELEASE_ASSERT below due to using mprotect with a wrong page size.
+    if (sysconf(_SC_PAGESIZE) == ConfigSizeToProtect)
+        result = mprotect(&g_jscConfig, ConfigSizeToProtect, PROT_READ);
 #elif OS(WINDOWS)
     // FIXME: Implement equivalent, maybe with VirtualProtect.
     // Also need to fix WebKitTestRunner



Does this looks like a good idea?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200319/39bf12b4/attachment.htm>


More information about the webkit-unassigned mailing list