The underlying reported error is
* Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'condition "wrong extraction: File:///"'
Interesting that it's an asynchronous crash. What part of MacOS is paying such close attention to typed URLs?
It's really quite bad that a bug inside the data detectors can bring down a whole app.
Edit: some interesting links:
http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”")
There it validates it by asserting that the URL begins with 'file://', which it doesn't. It then converts to an NSInternalInconsistencyException which is what crashes the application, since it isn't caught.
The timing differences that people are seeing is because the NSSpellCheckerCheckString process checks the spelling only after your key entry has been idle for a short period.
checkDataDetectors will also run if you simply open a file or application with this text inside it in a text control. When declaring your text control class you can disable the automated spell checking and data extraction (which will run even if you have spell checking disabled).
There really is no need for this thread to be filling up with 'it works on x, doesn't work on y', since we know what causes this (any NSTextField on Mountain Lion).
If you want to have a look at it and can't read the crash report, attach to TextEdit with gdb
$ gdb /Applications/TextEdit.app/Contents/MacOS/TextEdit
<switch to textmate and type 'file://a/aaaaa' into a new doc'>
(gdb) <crash report>
(gdb) disass DDResultCopyExtractedURL
<dump of function>
However in my stupidity of attempting to tell you guys that I could type the aforementioned string, I caused Safari to hang. No crash, but it was complete and utterly useless.
- Skype (type and right mouse click)
- Sparrow (type and wait)
- Chrome (address bar)
- Safari (address bar)
- Mac App Store (search bar)
- Base (any textbox)
- terminal (in the preferences screen)
I only see someone who said that it was safe to type it in a software, but I can be wrong.
Listing every single app under the sun when it's completely obvious a common and widely used component (doesn't matter what's its name so really no need to know Cocoa and that it's probably NSTextView) is used is acknowledging it as voodoo.
Right now, Sublime seems to be the only one. Anyone care to try TextMate?
People act completely stupid when it comes to their OS. HOLY SHIT THERE'S A STANDARD TEXT FIELD CLASS?!?!?! APPLE IS DOOMZ0R3D!! Be a champ and submit these kind of things to your local devs and (as the super "hacker" posters say) carry on...
I'm so happy I have nice friends.
sqlite3 ~/Library/Messages/chat.db "delete from message where text like "%File:%"
Find field in chrome.
(This is true of basically every OSX app there is)
In the OP for example:
6 AppKit 0x00007fff921dbd1a checkDataDetectors + 536
7 AppKit 0x00007fff921d9429 NSSpellCheckerCheckString + 13334
8 AppKit 0x00007fff921d5f9f -[NSTextCheckingOperation main] + 152
7 AppKit 0x00007fff921d9429 NSSpellCheckerCheckString + 13334
- 'File:///' typed slowly
- 'File://a' typed slowly
- 'File:// a' typed at any speed.
- 'File:///' typed quickly
- 'File://X' (X being any non-whitespace character) quickly
- 'File://X ' (any number of non-whitespace followed by any whitespace) at any speed
(remember to change to File)
Chrome survives, while Safari either crashes or behaves erratically up to being unusable. Firefox requires slight modifications to the event, but I'm bored.
That was a disaster. This is a bug.
Edit: Here's the same bug in VLC: https://trac.videolan.org/vlc/ticket/7268
It's probably easier to try than it is to find out why to try it...
It also has great tmux support built into the client.
How did this bug survive the testing process?
Wait. I think I just answered my own question.
I can't believe there's no-one at Apple using i18n keyboard layouts and Terminal.app.
It's not like typing "~" is an uncommon event on the command line....
Meanwhile, VLC fixed the same bug (typing ~ in the VLC.app UI textfields) in about 30 minutes.
Tried it in Safari and Firefox too, no issues.
OK, it also crashes Safari when capitalized.
(Chrome version 24.0.1312.57 really doesn't crash for me on Mac OS X Mountain Lion. Safari and TextEdit do, though.)
(not a reduced testcase - it's more of a brute force)
You can also trigger a mailto: link that crashes Mail:
The assert that fails is this:
assertion on /SourceCache/DataDetectorsCore/DataDetectorsCore-269.1/Sources/PushDown/DDResultExtraction.c:1576 "CFStringHasPrefix(urlVal, CFSTR("file://"))" failed :wrong extraction: File://
There's an extra slash at the end, but I left it out because it crashes Safari.
Also Sent myself an email (from the iPhone) with File:/// as the subject (and in the body for good measure).
The Mail.app won't crash on the incoming email, but it won't open that message.
In one instance the Sparrow crash caused the entire mail library to be corrupt and I have to download all my mails again.
Interesting, though, what exactly causes this bug. It seems as if the built-in spellcheck seems to misinterpret the string "file:///" as some sort of alien construct, or perhaps false typed directories trigger some sort of lockdown. Either way, it's very puzzling how this sort of thing made it past the OS X developers, especially with Apple's level and standard of ultra-high quality control.
"- but, it should never happen?!"
"- so, make it not happen, ever"
Asserts make the code blow up, which can make a problem easier to spot in dev/testing. In production it seems better to throw an exception, even if the program can't handle it well and just has to quit nicely.
I like your defensive programming strategy - see if the tires are flat before you get out on the highway.
(Edit: talking about bugs, HN formatting won't let me put http:/// in double quotes - it eats the closing quote.)
Now the programmer who developed DataDetectors wanted to make sure (maybe for tests) that a subcomponent was fed only valid file-urls (that is: file:/// is OK, File:/// not) and therefore inserted an assert-statement. Assertions stop the program flow if their condition is not met (an exception is thrown) and normally a code block upstream should handle this case.
I can only speculate, but either the assertion was left in the code despite being only intended for debugging/testing (ie. it was meant to be there only temporarily) or the upstream code has a bug that causes it not to catch the exception.
Either way, it is not handled and therefore bubbles up the whole code chain until some monitor in OS X or Objective C terminates the program because it sees a program error.
Someone at Apple forgot a test case feeding text with File:/// to DataDetectors.
There's obviously and blatantly a combinatorial explosion of possible inputs into a textbox so it's physically impossible ("physically" as in: "there aren't enough atoms in the universe to build a machine able to handle this) to test all the possible inputs.
By your logic when the terrible endless loop in the Java floating-point parsing library (you could stuck any JVM by trying to parse: 2.2250738585072012e-308) was discovered, it's because:
"Someone forgot to write a test case trying to parse 2.2250738585072012e-308"
And concerning the Java FP bug: yes, someone forgot to test the corner cases of the Java FP range.
You don't need to test every FP number out there, but you absolutely need the highest, lowest, highest+1, lowest+1, zero, +/-infinity, division by zero and if you are good highest +0, lowest + 0 and some conversions from and to long, int etc.
This seems like hardly something that outweighs the massive performance improvements.
I found a workaround:
defaults write $DOMAIN DisableDataDetectors YES
Credit goes to: http://www.macosxtips.co.uk/index_files/data-detectors-in-ma... The following works for Adium:
defaults write com.adiumX.adiumX DisableDataDetectors YES
ETA: Doesn't seem to persist. Might be sleep/awake or some sort of refresh/timeout. Investigating...
A shell script that patches the offending binary and bypasses the issue:
Copy script contents to a file, then execute (using sudo)
This has been tested by others with positive results. It is however a community provided fix.
Original file is backed up before patching.
Just tried in Mobile Safari and Noted in iOS 6.1, no problems there.
Also, are you sure you're both affected and doing it right? It only affects 10.8.x and you have to capitalize the "F".
Bug report says 10.8.2. I don't see this problem on 10.7.5 as the addendum mentions no problem in Lion.
I'm typing File:/// in every textbox I could find. This is some weird fun. Way to spend my Saturday morning.