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