Do Not Type "File:///" in OS X

http://openradar.appspot.com/13128709

by 67726e • 13 years ago

469 175 13 years ago

openradar.appspot.com

0x014• 13 years ago

I wish they'd just fix the bug where typing "~" crashes Terminal.app (depending on your keyboard language) :(

pivo• 13 years ago

Have you tried iTerm?

0x014• 13 years ago

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 ~)

niggler4• 13 years ago

You mean iTerm or iTerm2 http://www.iterm2.com ?

derleth• 13 years ago

> I wish they'd just fix the bug where typing "~" crashes Terminal.app (depending on your keyboard language) :(

How did this bug survive the testing process?

Wait. I think I just answered my own question.

0x014• 13 years ago

It's quite terrible. I even reported it on bugreport.apple.com on 10.8.0, but neither 10.8.1 nor 10.8.2 fixed it.

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.

AngryParsley• 13 years ago

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.

0x014• 13 years ago

Set keyboard to Norwegian. Type Ctrl+"¨" (they key that is the dead-key for ñ, if you were to type Alt+"¨"+n) Crash.

Edit: Here's the same bug in VLC: https://trac.videolan.org/vlc/ticket/7268

mmastrac2• 13 years ago

This also happens in the address bar of Chrome. Great fun.

0x014• 13 years ago

Wow, and it takes down the entire browser, too, and not just the tab!

akadien3• 13 years ago

No crash for me. Google must have patched it.

akadien3• 13 years ago

Geesh, tough crowd. No sense of humor.

(Chrome version 24.0.1312.57 really doesn't crash for me on Mac OS X Mountain Lion. Safari and TextEdit do, though.)

niggler4• 13 years ago

What version of chrome? Does not happen with 24.0.1312.56 or 24.0.1312.57

0x014• 13 years ago

Happens with 24.0.1312.57 on osx 10.8.2.

philip1209• 13 years ago

And it doesn't just crash one tab of chrome - it crashes the whole application

watmough• 13 years ago

Worst Easter Egg ever.

akadien3• 13 years ago

Cool!

MBCook2• 13 years ago

What an interesting bug.

Just tried in Mobile Safari and Noted in iOS 6.1, no problems there.

0x014• 13 years ago

The iOS Simulator's mobile safari seemed to survive OK on OS X too.

Fizzadar• 13 years ago

Spotlight, Finder, Chrome & Activity Monitor all crash; Terminal, Firefox & Sparrow are fine...

steeve• 13 years ago

And here I thought this was a Chrome bug...

niggler4• 13 years ago

I think the title needs to be amended to say 'OS X Mountain Lion' because the bug is not reproducible in Lion or Snow Leopard ...

program• 13 years ago

Confirmed that the bug doesn't affect Lion.

NelsonMinar• 13 years ago

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?

0x014• 13 years ago

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.

Edit: some interesting links:

http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”")

https://developer.apple.com/library/mac/#documentation/Found...

X-Istence5• 13 years ago

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.

pifflesnort• 13 years ago

Another link, with disassembly and a patch: https://twitter.com/landonfuller/status/297592929923502080

nikcub2• 13 years ago

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>

Also, this means the bug can't be exploited

shess• 13 years ago

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.

eludwig• 13 years ago

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.

taf2• 13 years ago

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...

czhiddy• 13 years ago

Highly unlikely. If you look at the backtrace, it's dying on an assert, not some random memory dereference.

im3w1l• 13 years ago

Seems to work in email though: http://news.ycombinator.com/item?id=5154915

KMag• 13 years ago

A remote DoS isn't remote code execution, but it's still an exploit.

eyko• 13 years ago

Not for me http://cl.ly/image/2i0S3r2b3q0d

delinka• 13 years ago

OS X version?

Bug report says 10.8.2. I don't see this problem on 10.7.5 as the addendum mentions no problem in Lion.

Vecrios• 13 years ago

I just did. I haven't seen a program crash this abruptly in a while, I'm happy.

JosephRedfern2• 13 years ago

Tried to tweet about this - Twitter client for OSX crashed instantly. Strange that it's not been discovered before!

JosephRedfern2• 13 years ago

Also crashes Alfred, Spotify, Calendar and Messages... It would probably be easier to make a list of un-affected apps.

zacharypinter• 13 years ago

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.

zhoutong• 13 years ago

Reproduced on Sparrow with success. Whenever you touch the line with File://(/) it will crash.

In one instance the Sparrow crash caused the entire mail library to be corrupt and I have to download all my mails again.

zbowling2• 13 years ago

Everything crashing:

  - 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.

mh-• 13 years ago

Add Messages.app to that list, I discovered as I stupidly tried to explain how to repro it to someone..

jhenkens• 13 years ago

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.

I'm so happy I have nice friends.

Flow3• 13 years ago

I dare not try it, but having that text as status on Facebook could crash those viewing my status using Safaris?

X-Istence5• 13 years ago

Typing it into a text box in Safari causes Safari to hang completely. Had to force quite it.

paulschreiber2• 13 years ago

That's because SublimeText doesn't use NSTextFields, and therefore, doesn't use Data Detectors. It's not voodoo.

paulschreiber2• 13 years ago

Seriously, people, learn how to read a backtrace. This is hacker news, not social-media-manager-who-claims-they-are-a-geek news.

ramchip• 13 years ago

I don't think the poster implied anything else.

Kronopath• 13 years ago

This bug is even crashing the crash reporter app as well. It vanishes shortly after appearing when I reproduce the bug in TextEdit.

rwl4• 13 years ago

Add Finder to the list. It dies if you try adding it to one of the color label names.

city41• 13 years ago

Sublime Text will crash if you type File:/// into the help textbox in the help menu.

(This is true of basically every OSX app there is)

chmars• 13 years ago

That because menu and help search are OS X functions.

ya3r• 13 years ago

Typing "File:///" in these also cause a crash:

Spotlight.

Find field in chrome.

peterkelly• 13 years ago

Can't reproduce it in Lion.

lucb1e• 13 years ago

Sounds like an easter egg gone horribly wrong

andymcsherry• 13 years ago

Crashes search in iTunes

lostlogin2• 13 years ago

Weird - doesn't for me, just asked me if I wanted to search App Store. But kills finder, makes chrome do odd stuff etc.

suyash• 13 years ago

Did not crash on LION MAC OS X 10.7.5

MysticFear• 13 years ago

Quick everyone go to their respective Apple Stores around the world. We will then see how long it will be fixed then ...

ajaimk• 13 years ago

It crashes finder. WTH?

speeder• 13 years ago

I would appreciate if someone can explain to me why I am feeling a urge to visit the office tomorrow only to see stuff crashing on my OSX workstation.

lostlogin2• 13 years ago

That feeling was me for 10+ years, mainly teenage ones. Not sure where it went, but I prefer working stuff these days.

gavinh• 13 years ago

LINUX

ajsharp• 13 years ago

This. IS. AWESOME.

nK0de• 13 years ago

Crashes:

XCode 4.5.2

TextEdit

iTunes

Preview

I'm typing File:/// in every textbox I could find. This is some weird fun. Way to spend my Saturday morning.

mmastrac2• 13 years ago

Fun exploit of this - you can use it to lock up Safari hard:

http://grack.com/hangsafari.html

(not a reduced testcase - it's more of a brute force)

You can also trigger a mailto: link that crashes Mail:

mailto:pete@bar.com?subject=File:///&body=File:///

ubershmekel• 13 years ago

Welp, sadly, Safari on Windows isn't affected.

antics• 13 years ago

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`.

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

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.

sgt• 13 years ago

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.

d0m• 13 years ago

It's a bug, it happens, let's move on.

gabrielgironda• 13 years ago

Figured you can crash Safari on page load with this. http://gironda.org/this_will_crash_safari.html

jneen• 13 years ago

File:///

jclem• 13 years ago

Does not crash:

- 'File:///' typed slowly

- 'File://a' typed slowly

- 'File:// a' typed at any speed.

Does crash:

- '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

spiritplumber• 13 years ago

Fail:///

kc0bfv2• 13 years ago

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?

lloeki3• 13 years ago

Sometimes (especially in dynamic-land) you assert stuff before doing some processing, so that stuff does not blow up halfway but upfront.

"- but, it should never happen?!"

"- so, make it not happen, ever"

kc0bfv2• 13 years ago

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.

dspig• 13 years ago

Maybe because of this: http://stackoverflow.com/questions/2035595/c-xcode-assert-ev...

bsno• 13 years ago

Do not send this string in an iMessage, unless, of course, you're evil.

jensen2k• 13 years ago

I put ut a JSFiddle crashing Safari. This is fun. http://jsfiddle.net/EJzhH/3

human_error• 13 years ago

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.

kunai2• 13 years ago

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.

omaranto• 13 years ago

Doesn't Apple's quality control only apply to hardware? I hear people complain about bugs and just shear ugliness of their software pretty often.

kunai2• 13 years ago

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.

nukerhazz2• 13 years ago

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.

h4rrison• 13 years ago

It's definitely a spell check bug, I've got that feature turned off (always hated it) and none of this is doing anything for me.

JeffKnol• 13 years ago

How do you turn it off globally? Even removing the AppleSpell.service directory and quitting the accompanying process doesn't seem to work.

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".

nukerhazz2• 13 years ago

Binary patch, for entertainment purposes only, do not actually use: http://twitter.com/landonfuller/status/297592929923502080

danabramov• 13 years ago

Landon is a really nice guy, by the way. He is the author of PLCrashReporter library and helped us out making it work with MonoTouch.

nu2ycombinator• 13 years ago

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. :)

lloeki3• 13 years ago

The word is out so it's only a matter of minutes for people to come up with this Safari DOS in Javascript:

https://gist.github.com/4696484

(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.

scottbartell• 13 years ago

Anyone else wasting a lot of time typing "File:///" into every input in every program...? Just because they were told not to.

VPrime• 13 years ago

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.

46Bit2• 13 years ago

Send yourself 80 messages and it'll open again, then delete the conversation the File:/// is in.

cranklin• 13 years ago

in other words, this would wreak a lot of havoc: window.location = "File:///"

djbender• 13 years ago

"Not allowed to load local resource: file:///"

X-Istence5• 13 years ago

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.

lovamova• 13 years ago

Another reason to use Snow Leopard, best operating system until now.

TallboyOne3• 13 years ago

Yes because every day one types "File:///".

This seems like hardly something that outweighs the massive performance improvements.

Jyaif• 13 years ago

improvements ?!

TallboyOne3• 13 years ago

Can someone explain this error to me simply, like one might talk to a golden retriever?

iSnow2• 13 years ago

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.

TallboyOne3• 13 years ago

Thank you, iSnow! Makes perfect sense.

martinced• 13 years ago

"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"

Yeah. Sure.

sly010• 13 years ago

There was an x-ray machine called "Therac-25" which had a chance of killing you if the operator typed a specific (non-lethal) configuration too fast.

http://en.wikipedia.org/wiki/Therac-25

That was a disaster. This is a bug.

smtddr• 13 years ago

This is why I never want to work in dev or qa for medical machines. If I were involve in this product's design, the guilt would destroy me.

stallmanuu• 13 years ago

irc.mactalk.com final solution! room cleared

emehrkay• 13 years ago

Seems to crash just about everything except Textmate 1&2 which is strange because they both use the built-in spellchecker

quasque• 13 years ago

This is a bit nostalgic. Back in the day, Opera used to crash if you typed http:/// into the address bar.

(Edit: talking about bugs, HN formatting won't let me put http:/// in double quotes - it eats the closing quote.)

maximem• 13 years ago

Now when I try to acces F ...acebook it crashes... calling File://[.]

bla22• 13 years ago

This is the original discovery, before shess copied it into openradar: http://crbug.com/173405#c17

smackfu• 13 years ago

Original bug report was interesting, just typing "F" in the address bar and getting a reproducible crash that no one else could repro.

bla22• 13 years ago

"F" probably autocompleted to "File:///" on that person's profile.

agracey• 13 years ago

It just crashed an App that I was working on and then crashed XCode itself.

philfreo• 13 years ago

iMessage your friends with this string and their Messages app will start crashing. Fun!

zero_z3r0• 13 years ago

For the impatient among us...

A shell script that patches the offending binary and bypasses the issue: http://pastebin.com/pqyePXqa

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.

frostnovazzz• 13 years ago

Works fine in sublime text 2

josteink• 13 years ago

Also, do not send file:/// to anyone using iMessage on their computer.

elptacek2• 13 years ago

ETA: Yeah... I can't make this stick. So it kinda-sorta works, but is not a real workaround. Guess I'm glad I kept testing it...

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...

elptacek2• 13 years ago

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.

Do Not Type "File:///" in OS X

Related Stories