Hilariously, this bug seems to also crash the Mac error reporter, maybe because it has the evil string in it. I did manage to copy and paste a crash dump before the crash reporter crashed: http://pastebin.com/UkhERvaA
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?
From the openradar bug, it is obvious that the bug is inside the "Data Detectors" thing. Looks like it triggers on anything starting with file:// (+/) case-insensitive, but then something later in the data extraction makes the incorrect assumption that the string should start with file:// (+/) lowercase, and throws an assert.
It's really quite bad that a bug inside the data detectors can bring down a whole app.
checkDataDetectors will extract 'File://a/' - or any other 'complete' file URL - which at a minimum is a schema (file://) and a path '/' - as a valid data URL and then pass it to DDResultCopyExtractURL, which does some additional sanity checking.
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
(gdb) r
<switch to textmate and type 'file://a/aaaaa' into a new doc'>
(gdb) <crash report>
(gdb) disass DDResultCopyExtractedURL
<dump of function>
Unhandled exceptions can't be exploited in general, because they safely unwind the stack and terminate the application. This crash is just an unhandled exception. By contrast, a segfault (at an address other than NULL) would be more interesting from a security perspective.
The data detectors, at least in my TextEdit were turned off (never touched it before) so typing the aforementioned string doesn't cause any issues.
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.
If you're stuck because you typed this and now your app is automatically crashing itself all the time, go to System Preferences, under Language & Text, Text, uncheck "Correct spelling automatically" _and_ "Use symbol and text substitution". Both need to be unchecked.
You can use TextExpander to work around it temporarily. Just map {The bad string that starts with 'F' that I cannot type here} to file:/// and it seems to add some protection.
- Skype (type and right mouse click)
- Sparrow (type and wait)
- Chrome (address bar)
- Safari (address bar)
- Tweetbot
- Twitter.app
- Mac App Store (search bar)
- Base (any textbox)
- terminal (in the preferences screen)
Not crashing:
- SublimeText
Pretty much each and every text box on the entire system.
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.
The likelihood of python/ruby/PHP/etc. programmer being able to interpret a native code stack trace is... what? Probably quite low. They might not even know what the function call names imply. And yet they'd fit perfectly in to this site's readership.
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...
Oh, please. What is a standard text field class doing with the text inputted into it that would cause an entire app to crash? It's a ridiculous scenario.
Would you have the standard text field run in a separate process sandbox? Or not have standard widgets shared between apps? Or just try real hard to write code without bugs?
The fun thing about having it in messages.app, is it is actually a bug on the RECEIVING end of messages.app. And I can't seem to delete the message before the app crashes again.
The cause of this bug seems to be the OSX system spell checker; I've crashed a few applications to take a look at the dumps, and so far they common point of failure seems to be that they all have some call to something like `NSSpellChecker`.
This explanation makes sense to me because the spell checker is integrated very tightly into the user-facing text entry experience across the board in OSX. It is one of the few bits of code that could explain reliable failures across applications that we've been seeing.
I've disabled the spell checker a long time ago, but it still happens. So NSSpellCheckCheckString is still being invoked even though the spell check is not running.
I try to avoid upgrading OSX. When a new version comes out, I wait for a hardware refresh and just get a new Mac (Apple has a nasty habit of disregarding backwards compatibility, and it's really nice to be able to do stuff like run older powerpc programs)
EDIT: the [deleted] comment was 'I miss snow leopard'
Even that strategy isn't enough. I bought a Retina MBP with Lion pre-installed, which was the only configuration they sold, so you'd think it would have been pretty well tested. It turned out that the Lion video drivers couldn't handle the retina display. I had full machine crashes three times a day. Others online had the same problem, and some who were beta testing Mountain Lion said the new video drivers had cured their crashes. As soon as ML was released, I took the free upgrade, and the crashing stopped.
I then upgraded my kids' Snow Leopard Mac to Mountain Lion so I'd only have one Mac OS to admin (along with my Windows, Linux, iOS, and Android machines...sigh). The Mountain Lion upgrade caused all sorts of headaches on the kids' machine.
Moral: The new Mac OS version you buy might not be compatible with your Mac, even if it's the OS that came with it.
When you have a business, its far easier to just purchase a new machine and expense it than it is to upgrade existing machines. Time is far more value than money, and I'd much rather spend 3K for a new machine than waste a day or a week struggling with an upgrade issue and dealing with AppleCare.
PS: it's eligible for section 179 accelerated depreciation and sales-tax free in NY thanks to ST 121.3
Please note my reply was meant to be taken as a joke. I expect most people don't need to refresh their Apple gear on a yearly basis, but that is a bit of the stereotype of an enthusiastic Apple fan, and your post can be taken humorously to fit that image. Of course with Apple the answer is always more hardware. :-)
> Apple has a nasty habit of disregarding backwards compatibility
On the hardware front, every single major update runs better than the one before here (Mid '09 MBP 13", originally under Leopard). Only issues were the battery on Lion an Mountain Lion on both .0 and .1 minors, which was a bug that affected everyone.
Backwards compatibility refers to newer software/hardware not supporting older software/hardware. For example, Apple axed the rosetta powerpc support (which allowed you to run older software after apple switched to intel CPUs) in Leopard. I still keep a PowerBook G4 just for MacDraw.
Rosetta is optional but supported on Snow Leopard, and gets downloaded automatically on demand. Seven years of transition (assuming SL stopped to be supported when ML was released) to Intel was more than enough for active software to be ported.
You just can't carry legacy code indefinitely, you have to stay focused or you'll be all over the place and suffer death by a thousand cuts.
I intuitively agree as a programmer, but in practise, the focused 10.7/10.8 line has been pretty buggy compared to the legacy-happy 10.6; and the legacy-happy Windows 7 was a smash hit compared to the focused Windows RT. Of course, it might be even worse with Rosetta added to the mix...
I've also given away my Mid-09 MBP because 10.7 Safari was terrible without an SSD ("blank page" bug) :(
Chrome survives, while Safari either crashes or behaves erratically up to being unusable. Firefox requires slight modifications to the event, but I'm bored.
Can you give us the steps to reproduce? I googled around but couldn't find the bug. I also tried a few different languages and I can't get Terminal.app to crash.
Maybe I should, but 10.8's Terminal.app seemed to have everything I need (well, except for the crash reporter ruining my work every time I forget and type ~)
You know, it's funny. I said the exact same thing you did, then a friend convinced me to try iTerm2 about a year ago. I still couldn't put my finger on what's better about it, exactly, but I've never considered going back after the first day. It just feels right.
It's probably easier to try than it is to find out why to try it...
Doesn't crash my Terminal.app. I use a swedish keyboard. Perhaps you could create a new clean account on your computer and try it there? You can always delete the account afterwards.
Yup, and that's why I suggests you create a new fresh user and try it there. If the bug doesn't show there it's something in your personal settings somewhere, if not it's in the system settings.
I'm also running the latest version of Chrome on Mountain Lion on a current Macbook Air, and I can't reproduce this. Entering file:/// just shows me "Index of /" as expected.
If you have Xcode you can reproduce the crash in a scratch Xcode project. Drop an NSSearchField into a window, run the app, enter you-know-what, and boom. (I used NSSearchField since that's what I found most easily crashes Finder, VoodooPad, and System Preferences. Maybe NSTextField works as well.)
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.
I sent an iMessage (from iPhone) saying File:/// to my iMac and it crashed iMessage on the other end.. and now messages app crashes every time I try to launch!
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.
Tried it out by sending an email to myself (from webmail) and opening the mail in Mail.app. Mail.app doesn't crash, but if you hit reply to the message and put the cursor on the "File:///" part, it does crash.
Hilarious. I pranked my friend with this, and now he's pissed. Oh well, it was certainly worth it.
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.
Up until 10.6, actually, Apple used to produce very good, generally bug-free software. Starting with 10.7, they've begun to rush their software just because they have, say, 4 new "features". The yearly release cycle is partly to blame, but even then, iOS bugs are much more minor.
Several people have said that these apps are crashing at an assert. How did asserts make it into production code? Is it just a C thing to make them debug-only?
My understanding is that asserts are for debugging, and exceptions/more robust error handling are for production.
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.
Somewhere in the system is a friendly program called "DataDetectors", which sniffes at text so find out if there are links in it which should be highlighted by the application handling the text.
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.
"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"
I am not sure why you sound so angry, but let me try to explain: Every time you build in an assertion like that you should have a test case to prove the program handles it like you intended it to.
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.
Tested this a bit more. It seems to work on Adium "only some of the time." I am told it works for Colloquy. It does not work for the Google Chrome Browser, TextEdit or Mail.
I think it only affects 10.8. I have tried the suggested methods of this thread in Chrome, TextEdit, iTunes, terminal and Safari but nothing happened in 10.6.8.
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.
so, uh anyone else sense a zero day exploit? <a href="File:///<insert code here>">click me</a>... not saying that will work, but usually if you can hard crash something you just found some corruption in memory maybe bad use of memcpy, sprintf instead of snprintf... something along those lines...
I never felt need to upgrade my snow leopard. This bug is not happening in Snow leopard. I am going to Apple store and try this on one of the display laptop. :)
None of the browsers will redirect from the web to local, nor will they allow you to load images and whatnot from local either, so doing it that way won't work either.
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?