This is missing the script; Thomas provided it to me.

Deleted: Create clipboard contents.scpt 1.7 KB

Create clipboard contents.scpt 1.7 KB Download

Erik, you were the last one to mess around with the pasteboard, right?

The OP wants this other archive attached. It contains three things: a screenshot, the AppleScript that I posted for the OP in comment 2, and a crashlog. crsym isn't symbolicating it, but the crash is pretty clear:

0   CoreFoundation                      0x00007fff8c03a03c __exceptionPreprocess + 172
1   Google Chrome Framework             0x000000010d401f54 ChromeMain + 21096420
2   libobjc.A.dylib                     0x00007fff89f5676e objc_exception_throw + 43
3   CoreFoundation                      0x00007fff8c039eed +[NSException raise:format:] + 205
4   Foundation                          0x00007fff8d148b02 -[NSMutableRLEArray replaceObjectsInRange:withObject:length:] + 142
5   Foundation                          0x00007fff8d191ebb -[NSConcreteMutableAttributedString setAttributes:range:] + 95
6   AppKit                              0x00007fff867cb3f4 _NSMakeAttributedStringFromCarbonATSUIData + 846
7   AppKit                              0x00007fff8683c459 +[_NSRTFPboardTypeConverter _getConvertedDataFromPasteboard:atIndex:] + 142
8   AppKit                              0x00007fff8658a7c4 -[NSPasteboard(NSTypeConversion) _dataWithConversionForType:] + 316
9   AppKit                              0x00007fff8683bbc9 -[NSPasteboard stringForType:] + 31
10  Google Chrome Framework             0x000000010e1874a0 ChromeMain + 35274032

It seems like the style information is bogus and we're crashing deep inside of AppKit. We may need to wrap this in an exception catcher.

Deleted: Archive 11.31.56.zip 210 KB

Archive 11.31.56.zip 210 KB Download

Application Specific Information:
Crashing on exception: NSMutableRLEArray replaceObjectsInRange:withObject:length:: Out of bounds

Huh, the style info should not be bogus, though. It's coming from copying a
styled textfield from the classic Carbon API. And pasting it into other
apps such as TextEdit works, preserving the style, without a crash (though,
maybe they're all catching the exc?)
I can reproduce the issue all the time when copying from a certain text
field of a certain app (which is - don't laugh - Real Studio).

Jeez, the captcha feature for this forum is not working for me at all. It
keeps telling me that I need to retry, even though I've clicked on a dozen
tiles or more, going thru several iterations of identifying street numbers
and store fronts. At least commenting thru email works painlessly.

I wanted to add that I, in fact, can not easily reproduce it any more. I
used to get this crash repeatedly, but suddenly I only get it with the
sample data I sent you but not with new copied text. Typical.

So yes, maybe the data was corrupt indeed, and it may even be a bug in
Apple's framework.

I hope a simple exception catching will handle this. As a fallback, please
try to fetch just the plain text.

What is the server ID of the crash?

Erik, I entered the ID in the bug report. Isn't that the right one? Though
that's a more recent crash report - of the same crash, though.

And the attached Applescript should make it easy to reproduce it. Avi was
able to reproduce it as well.

Thomas

When the crash is uploaded to our servers, it should be given a "server id".

Deleted: Screen Shot 2017-02-14 at 10.19.36 AM.png 19.9 KB

	Screen Shot 2017-02-14 at 10.19.36 AM.png 19.9 KB View Download

BTW, I was just able to reproduce the crash in one of my apps (it's a tool
to analyse the contents of the pasteboard, using all three APIs: Scrap Mgr,
Carbon and Cocoa). I now believe this is a bug in Apple's code, probably
where it attempts to convert the Scrap style into other rich types (such as
RTF).

Sigh.

Still, we in places wrap sketchy framework calls to catch exceptions and prevent crashes, so perhaps we can do that here.

I did some testing on 10.10.5, 10.11.6 and 10.12.3 with various Apple apps
and found this:

TextEdit and Finder crash on 10.10.5, but not on later versions - but they
then add logging about this exception to the Console. They then both fail
to paste the plain text content.

Script Editor pastes the rich text just fine (it's still Carbon based, I
suspect).

Pages crashes on 10.12.3.

I've reported this as a bug to Apple now as well. See
http://www.openradar.me/radar?id=6083703147069440

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

What can be helped to get this fixed in Chrome? Sure, Apple should do their own part, too. But since Apple does throw exceptions when accessing certain pasteboard contents, any app, including Chrome, should catch them to avoid crashing the entire app.

Should not be hard to locate the code in Chrome that reads from the Pasteboard and wrap it into try/catch, by ignoring any thrown exception, I'd think.

Searching for NSPasteboard shows that there are a fair number of locations where they're used: https://cs.chromium.org/search/?q=nspasteboard&type=cs

This seems like a good starter bug. Remarking as available.