1693202 - Crash in [@ -[ChildView pasteboard:item:provideDataForType:]]

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect, P3)

Description

[Markus Stange [:mstange]]

Crash report: https://crash-stats.mozilla.org/report/index/fcdab3ec-4397-45d2-b2a7-aa6e20210214

Reason: EXC_BAD_ACCESS / EXC_I386_GPFLT

Top 10 frames of crashing thread:

0 XUL -[ChildView pasteboard:item:provideDataForType:] widget/cocoa/nsChildView.mm:4414
1 AppKit __68-[NSPasteboard _setOwner:forTypes:atIndex:selector:usesPboardTypes:]_block_invoke 
2 CoreFoundation -[_CFPasteboardEntry resolveLocalPromisedData] 
3 CoreFoundation ___CFPasteboardHandleFulfillMessage_block_invoke_2 
4 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ 
5 CoreFoundation __CFRunLoopDoBlocks 
6 CoreFoundation __CFRunLoopRun 
7 CoreFoundation CFRunLoopRunSpecific 
8 CoreFoundation CFMessagePortSendRequest 
9 HIServices SendDragIPCMessage 

This crash was previously investigated in bug 1687268. The previous crash reports showed an Objective C exception. We landed a patch in that bug to stop the Objective C exception, and we were hoping that this would also fix the crash.

This new crash report is from a build that contains the fix from bug 1687268, and the exception message is gone - but the crash is still there.

Comment 1

[Markus Stange [:mstange]]

I've looked at this report a little more: https://crash-stats.mozilla.org/report/index/75c58d80-64d9-44a6-8dff-e08360210116

This looks like a use-after-free. Code:

// NSPasteboardItemDataProvider
- (void)pasteboard:(NSPasteboard*)aPasteboard
                  item:(NSPasteboardItem*)aItem
    provideDataForType:(NSString*)aType {
  NS_OBJC_BEGIN_TRY_IGNORE_BLOCK;

  if (!gDraggedTransferables) {
    return;
  }

  uint32_t count = 0;
  gDraggedTransferables->GetLength(&count);

We crash on the gDraggedTransferables->GetLength call, when dereferencing the GetLength function pointer in the vtable.

gDraggedTransferables is non-null and points somewhere into the heap, in this case it's 0x16d78b460 (%rdi). The first pointer in the object at that address (which we expect to be the vtable pointer) is 0x1dffffae53e0a9 (%rax), which is also somewhere in the heap. So it's not a vtable, because I think vtables would be located in the loaded range of the XUL library; XUL is loaded at 0x108ca0000 - 0x11066e000. We then look for a function pointer at the address 0x1dffffae53e0a9 + 0x18. And then the callq crashes. We crash with EXC_BAD_ACCESS / EXC_I386_GPFLT and the report has 0x0 as the crash address. I think this means that the value at 0x1dffffae53e0a9 + 0x18 is 0x0 but I'm not completely sure if this is reliable. In any case, it doesn't matter for the fix; we must make sure that gDraggedTransferables is never a dangling pointer.

And, looking at the places where gDraggedTransferables is set, it's clearly treated as a non-owning pointer and I don't see any guarantees that it never becomes dangling.

Comment 2

[Markus Stange [:mstange]]

Here's another report: https://crash-stats.mozilla.org/report/index/69e8e3e6-8afa-47d1-bfcc-1d0030210301#tab-details

This one includes the exception from bug 1693872.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.