Title: [232215] trunk/Source/_javascript_Core
Revision
232215
Author
mark....@apple.com
Date
2018-05-25 16:45:36 -0700 (Fri, 25 May 2018)

Log Message

MachineContext's instructionPointer() should handle null PCs correctly.
https://bugs.webkit.org/show_bug.cgi?id=186004
<rdar://problem/40570067>

Reviewed by Saam Barati.

instructionPointer() returns a MacroAssemblerCodePtr<CFunctionPtrTag>.  However,
MacroAssemblerCodePtr's constructor does not accept a null pointer value and will
assert accordingly with a debug ASSERT.  This is inconsequential for release
builds, but to avoid this assertion failure, we should check for a null PC and
return MacroAssemblerCodePtr<CFunctionPtrTag>(nullptr) instead (which uses the
MacroAssemblerCodePtr(std::nullptr_t) version of the constructor instead).

Alternatively, we can change all of MacroAssemblerCodePtr's constructors to check
for null pointers, but I rather not do that yet.  In general,
MacroAssemblerCodePtrs are constructed with non-null pointers, and I prefer to
leave it that way for now.

Note: this assertion failure only manifests when we have signal traps enabled,
and encounter a null pointer deref.

* runtime/MachineContext.h:
(JSC::MachineContext::instructionPointer):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (232214 => 232215)


--- trunk/Source/_javascript_Core/ChangeLog	2018-05-25 23:41:19 UTC (rev 232214)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-05-25 23:45:36 UTC (rev 232215)
@@ -1,5 +1,31 @@
 2018-05-25  Mark Lam  <mark....@apple.com>
 
+        MachineContext's instructionPointer() should handle null PCs correctly.
+        https://bugs.webkit.org/show_bug.cgi?id=186004
+        <rdar://problem/40570067>
+
+        Reviewed by Saam Barati.
+
+        instructionPointer() returns a MacroAssemblerCodePtr<CFunctionPtrTag>.  However,
+        MacroAssemblerCodePtr's constructor does not accept a null pointer value and will
+        assert accordingly with a debug ASSERT.  This is inconsequential for release
+        builds, but to avoid this assertion failure, we should check for a null PC and
+        return MacroAssemblerCodePtr<CFunctionPtrTag>(nullptr) instead (which uses the
+        MacroAssemblerCodePtr(std::nullptr_t) version of the constructor instead).
+
+        Alternatively, we can change all of MacroAssemblerCodePtr's constructors to check
+        for null pointers, but I rather not do that yet.  In general,
+        MacroAssemblerCodePtrs are constructed with non-null pointers, and I prefer to
+        leave it that way for now.
+
+        Note: this assertion failure only manifests when we have signal traps enabled,
+        and encounter a null pointer deref.
+
+        * runtime/MachineContext.h:
+        (JSC::MachineContext::instructionPointer):
+
+2018-05-25  Mark Lam  <mark....@apple.com>
+
         Enforce invariant that GetterSetter objects are invariant.
         https://bugs.webkit.org/show_bug.cgi?id=185968
         <rdar://problem/40541416>

Modified: trunk/Source/_javascript_Core/runtime/MachineContext.h (232214 => 232215)


--- trunk/Source/_javascript_Core/runtime/MachineContext.h	2018-05-25 23:41:19 UTC (rev 232214)
+++ trunk/Source/_javascript_Core/runtime/MachineContext.h	2018-05-25 23:45:36 UTC (rev 232215)
@@ -438,6 +438,8 @@
 #else
     void* value = instructionPointerImpl(const_cast<PlatformRegisters&>(regs));
 #endif
+    if (!value)
+        return MacroAssemblerCodePtr<CFunctionPtrTag>(nullptr);
     return MacroAssemblerCodePtr<CFunctionPtrTag>(value);
 }
 
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to