Live data from Hacker News

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

openradar.appspot.com

181–190 of 206 posts

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

#183
post #147

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

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

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

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

#184
post #53
post #49

Earlier quoted context omitted.

[deleted]

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'

> When a new version comes out, I wait for a hardware refresh and just get a new Mac

Apple must love you.

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

#185
post #127
post #97

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?

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"

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.

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

#188
post #173

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

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

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

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

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

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

#190

Earlier quoted context omitted.

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

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

I'm not a social media manager. I'm an engineer. I was making list from casual testing and giggling.
Post reply on HN