Bug 186004 - MachineContext's instructionPointer() should handle null PCs correctly.
Summary: MachineContext's instructionPointer() should handle null PCs correctly.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Lam
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-25 16:34 PDT by Mark Lam
Modified: 2018-05-25 16:46 PDT (History)
5 users (show)

See Also:

Attachments
proposed patch. (2.12 KB, patch)
2018-05-25 16:42 PDT, Mark Lam 		saam: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Lam 2018-05-25 16:34:19 PDT 
instructionPointer() returns a MacroAssemblerCodePtr<CFunctionPtrTag>.  However MacroAssemblerCodePtr's constructor does not accept a nullptr 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) 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.
Comment 1 Mark Lam 2018-05-25 16:35:03 PDT 
Note: this issue only manifests when we have signal traps enabled, and encounter a null pointer deref.
Comment 2 Mark Lam 2018-05-25 16:42:01 PDT 
Created attachment 341354 [details]
proposed patch.
Comment 3 Radar WebKit Bug Importer 2018-05-25 16:42:53 PDT 
<rdar://problem/40570067>
Comment 4 Mark Lam 2018-05-25 16:46:07 PDT 
Thanks for the review.  Landed in r232215: <http://trac.webkit.org/r232215>.