Typing These 8 Characters Will Crash Almost Any App On Your Mountain Lion Mac

An anonymous reader writes "All software has bugs, but this one is a particularly odd one. If you type "File:///" (no quotes) into almost any app on your Mac, it will crash. The discovery was made recently and a bug report was posted to Open Radar. First off, it’s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. That’s not exactly good news given that this is the latest release of Apple’s operating system, which an increasing number of Mac users are switching to. ... A closer look shows the bug is inside Data Detectors, a feature that lets apps recognize dates, locations, and contact data, making it easy for you to save this information in your address book and calendar."

Comments

printf

[Sigvatr]

C-strings strike again.

Re:printf

[Anonymous Coward]

I wonder if the bug will lead to possible RCE due to memory corruption.

Re:printf

[Anonymous Coward]

Not likely. It crashes due to an assertion failure and subsequent exception being thrown.

Re:printf

[Anonymous Coward]

Here speaketh the Apple fan. No matter what... it's a good thing.

Re:printf

[Anonymous Coward]

Why do you assume it's a C-string issue? An exception was thrown, indicating no real corruption just an unhandled exception.

Re:printf

[Anonymous Coward]

On a file not found error, isn't it better to return "file not found" instead of "commit suicide" ?

Re:printf

[Anonymous Coward]

My comment had nothing to do with Apple, it has to do with good programming practices. Catching mistakes as soon as possible is a good thing, no matter who is writing the software. assert() is a programmers best friend, regardless of who he works for.

Re:printf

[Anonymous Coward]

Yes, crashing a computer over a trivial error is a good thing; kind of like how Google's networks goes down whenever someone tries to include an illegal character in an email address.

Re:printf

[Anonymous Coward]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Re:printf

[Anonymous Coward]

When you detect that your program is in an inconsistent state, is it better to continue executing, possibly corrupting data and granting an attacker access to your system, rather than aborting the program and providing a stack trace to help diagnose why things went wrong?

Re:printf

[Anonymous Coward]

If it caught the mistake it wouldn't crash. That's not error handling.

Re:printf

[peragrin]

What is funnier that file:/// doesn't work.

The Captil F is required. at least in my limited testing.

Re:printf

[jones_supa]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

Re:printf

[jones_supa]

Good point.

Re:printf

[TheRealMindChild]

Exceptions should be exceptional. A bad string isn't exceptional

Re:printf

[Anonymous Coward]

Here speaketh the Apple fan. No matter what... it's a good thing.

Yes, input validation is usually a good thing and no amount of you hating Apple Inc is going to change that.

Re:printf

[Dahamma]

No, it's better to return an error or thrown an exception rather than assert when the input to a function is perfectly reasonable but not what you expect.

And, in the end, who knows. Maybe it was the caller aborting by not handling the error/exception. In which case it's STILL bad coding by someone, as this is not an exceptional case...

Re:printf

[Anonymous Coward]

Hey its just a GUI event indicating that the user entered something in a text bar.

When that event gets processed and an exception occurs while the user input is parsed no actual state modifying operation occured yet. Atleast in my happy world where we don't modify state until we're done figuring out what the user wanted.
If it wasnt even able to figure out what the user wanted and concluded that the input is unparseable, reset the input field, forget about that event and its still a consistent state.

Re:printf

[EvanED]

Yes, input validation is usually a good thing and no amount of you hating Apple Inc is going to change that.

That's true. But a crash is not the way to handle invalid input.

Re:printf

[Savage-Rabbit]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

$ man assert

NAME
          assert -- expression verification macro

SYNOPSIS
          #include

          assert(expression);

DESCRIPTION
          The assert() macro tests the given expression and if it is false, the
          calling process is terminated. A diagnostic message is written to stderr
          and the abort(3) function is called, effectively terminating the program.

          If expression is true, the assert() macro does nothing.

          The assert() macro may be removed at compile time with the cc(1) option
          -DNDEBUG.

Somebody forgot to remove some debugging code, embarrassing but hardly something that hasn't happened before and definitely not the end of the world as we know it.

Re:printf

[Savage-Rabbit]

What is funnier that file:/// doesn't work.

The Captil F is required. at least in my limited testing.

Typing 'file:///' opened Finder.app from Safari's address bar just fine on my machine.

Re:printf

[Anonymous Coward]

case sensitive URL handlers is a good thing? that's straight crazy. assertions in library code are a good thing? hell no. you should exit gracefully doing nothing with an error code or an exception.

Re:printf

[black3d]

That's what he said.. you need a capital F

Re:printf

[fyngyrz]

C-strings strike again.

Nope. Lousy programmers strike again. There's nothing at all wrong with c-strings. There is, however, a sufficiency of lousy programmers who lack the skill to handle perfectly simple data structures. Seriously, if you can't handle a zero terminated string or keep from overrunning an array, it's not the string format that's the problem. It's you.

Assuming the problem here is a string problem may be jumping the gun, too. Could just as easily be something else.

Re:printf

[Anonymous Coward]

I agree with you, you couldn't abort on bad input.

However, based on my interpetation of what is happening, this isn't what is happening. My expecation is as follows:

The user types something in an address bar.

That string is passed to hypothetical function 'process_uri'.

'process_uri' sees that it is a file uri, and passes it to the hypothetical function 'process_file_uri'.

'process_file_url' sees that it wasn't given a file uri, and aborts.

The problem ISN'T that the use gave bad input. If process_uri was given a URI it didn't recognize, it would have generated a proper error and not called anything. If process_file_url was given a path to a file that didn't exist, it too would have generated a proper error. The problem IS that process_uri and process_file_uri have different expectations on what constitutes a proper file uri.

Re:printf

[Anonymous Coward]

Not likely. It crashes due to an assertion failure and subsequent exception being thrown.

Yeah. Data Detectors on Macs is just like Semantic Desktop on KDE. When I make a fresh install of the OS, disabling these pesky little "features" is one of the first things I do. I'm glad somebody somewhere out there finds them useful but I definitely don't.

Re:printf

[Anonymous Coward]

Having customers see asserts hit in production code, instead of failing gracefully, is not a good programming practice.

Re:printf

[Anonymous Coward]

Try to understand what he's saying before you throw bullshit like that.

Re:printf

[Anonymous Coward]

Moreover, why should it be invalid input.

Re:printf

[Anonymous Coward]

right, it's an assertion failing. The first check is doing a case-insensitive comparison, the assertion is case-sensitive. so file:// won't crash it but File://, FILE://, fiLE://, and FilE:// all will.

Re:printf

[Anonymous Coward]

I wish more people realized this since it is INCREDIBLY important!

Asserts in the application data model are a good idea (since it must always be internally consistent).

It sounds like the bug is due to missing input validation polluting data model state so the fix shouldn't be to remove the assert but to fix the bug it found (that is, the missing/incorrect data validation on the mutator function).

Re:printf

[93 Escort Wagon]

It's interesting that this bug doesn't work on iOS - I just tried it (with the capital "F") on my iPad Mini, and all that happened was I got a warning in Safari about trying to access the local file system.

Re:printf

[Anonymous Coward]

It can be if the caller (or one of its callers, etc.) was supposed to be responsible for filtering out bad user input (and/or normalizing input). Then the routine that has the assert() is complaining about something that should be an impossible condition.

Re:printf

[Anonymous Coward]

Yes, input validation is usually a good thing and no amount of you hating Apple Inc is going to change that.

That's true. But a crash is not the way to handle invalid input.

Assertions come after input validation, and before the crashy bits.

Obviously an aborting on a failed assertion is not input validation, that doesn't mean it wasn't done, just not correct, and the assertion is justified.

Re:printf

[Anonymous Coward]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Sorry, but you are wrong.

By the time you fail an assertion, you better crash because you're not supposed to be there. The code in FRONT of the assertion is supposed to prevent that.

Assertions go between the input checking front, and the sane input needing rear. Their only purpose in life is to prevent an unknown state in the rear guts, not to do what should have been done up front.

Re:printf

[Anonymous Coward]

Considering the summary explicitly stated it only affected Mountain Lion, it's not interesting at all that iOS is unaffected.

Re:printf

[Anonymous Coward]

Seriously, if you can't handle a zero terminated string or keep from overrunning an array

If you're reading a string provided by the user or from some external source, relying on that string being null terminated is dangerous. How do you guard against a malicious attempt to avoid using null termination?

Captcha: debugs
How appropriate

Re:printf

[matunos]

And yet, unchecked input is the root of almost all software vulnerabilities

Re:printf

[AuMatar]

Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

Re:printf

[Jorl17]

This is not input checking. Input checking is checking the input for validity and acting accordingly. This is an assert, which is usually used as a way for programmers to make sure they didn't fuck up. If it is triggered, then the programmer fucked up. That's how it's supposed to be used.

Hence, the programmer fucked up, and this isn't input checking. It is nevertheless, IMO; a good practice to assert things (in debug code), but it also isn't checking for valid inputs, it's checking for programmer stupidity.

Re:printf

[AuMatar]

Asserts in testing are a good thing. Crashes in release are not. Asserts should be removed and you either process a sane default or abort the function returning an error, depending on the situation. That may even trickle up to the top level which may decide to exit gracefully telling the user what the problem was. But you do NOT crash.

Re:printf

[Obfuscant]

A bad string isn't exceptional

Especially when the interpretation of that "bad string" is supposed to be CASE INSENSITIVE and the "exception" occurs because one character is upper case.

URI are defined here, and the part that deals with the "file:" or "http:" part (called the "scheme") says this:

3.1. Scheme ...

Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case- insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

Emphasis mine.

This is a case of a programmer implementing a feature defined in a standard and ignoring the standard when doing so. Not lazy, just ignorant and stupid. Just like the ignorant stupid programmers who write javascript email address verifiers that refuse to accept valid email addresses because they contain characters like '+'. Those programmers should be shot.

Re:printf

[AuMatar]

The user never types in a null terminated string. They type in a sequence of bytes and the program turns it into a null terminated string. Strings with separate lengths work the same way- would you trust a length field coming straight from a user?

Re:printf

[Anonymous Coward]

Based on what you said, the summary title is incorrect. The programs aren't crashing, but rather are ending normally, just not when the user thinks they're telling it to.

Re:printf

[Darinbob]

Check the input, then deal with the error. Crashing is not dealing with the error. Assert should be used for "should never happen" cases, like pre/post-conditions.

Re:printf

[Darinbob]

To the user, there is no difference between crashing due to an assert or crashing due to following some strange pointer. Now the assert may give the developer more information to work with to fix the bug, but it should always be considered a major failing if a user ever sees it.

Re:printf

[matunos]

assert should be compiled away in production code. :-)

Re:printf

[Anonymous Coward]

I agree, a program should not crash but assert is not a crash.

Re:printf

[Anonymous Coward]

Somebody forgot to remove some debugging code

As far as I'm concerned, leaving assertions turned on in production code is a good thing (as long as they're just doing simple sanity checks that won't hurt performance). Actually _triggering_ one of them in production code is bad, but not as bad as letting the program continue into undefined behavior with data it never expected to see.

Re:printf

[Anonymous Coward]

The original argument was that the behavior they currently have is correct, which is absurd. Of course people make mistakes. The idea that their mistakes aren't actually mistakes is the problem.

Re:printf

[Darinbob]

Well, yes, but the last three jobs we've had to leave them in...

Re:printf

[Anonymous Coward]

Get out of the business. You are a fucking hack. Asserts are for pre-release debugging. Fucking moron.

Re:printf

[TheRealMindChild]

The point of assert is to set a breakpoint to go to during unit testing

Re:printf

[shutdown -p now]

assert() isn't really "debugging code". It's more of a sanity check - as the name implies, it's a macro that checks that expression is indeed true, where the standing assumption on this particular code path is that it must be true. If it's not true, then there's a logic bug somewhere in the program, and that may lead to data corruption or worse. So liberally sprinkling asserts around and leaving them in release builds actually helps - it's far better to fast-fail than to continue running the process in a potentially corrupted state, from security perspective.

Of course, the assert shouldn't be triggered in the first place - the fact that they somehow got into this state is itself a bug, which they should fix. Still, kudos to Apple folk for handling this one in a manner that makes it useless for an exploit.

Re:printf

[shutdown -p now]

A perfect program should not crash for any reason - but very few programs of any considerable size are perfect. And even well-written software has bugs.

Asserts are meant to indicate that the condition should always be true on this particular code path - that's why it's called an "assert". It's not a tool to check for exceptional conditions and gracefully handle them - you have conditional statements (and exception handling, if the language supports that) for those purposes. You use assert after you have used a conditional to fork off onto a code path to assert that all the implied conditions are, indeed, true. If the conditions are not true, it indicates a bug in the logic of the program - the assumption was not correct. There is no way to gracefully handle that, because you don't know where exactly the problem is, and therefore you can no longer rely on the state of your process being correct. If you hit an assert, it means that some objects you thought to be alive are now dead, and you might have dangling pointers around. Or maybe some variables that you think have correct values in them have something outdated and completely irrelevant. Either way, if you keep running, you risk integer and buffer overflows - and from there, execution of arbitrary injected code. From security perspective, this is the worst scenario you can end up with, especially for an application facing the network or processing external inputs from the network. Fast-fail (i.e. consistently crashing right away) is much preferable to that, even if it inconveniences the user.

Re:printf

[shutdown -p now]

Asserts should not be hit. If they are hit, the program is in a bad, unexpected state. If your program is in a bad, unexpected state, you want to kill it ASAP, production code or no.

The only reason why asserts are usually compiled out in non-debug builds is because those extra checks are not free, and because the assumption often is that in production code, you have no bugs - and therefore the asserts will never fail anyway, so why bother? But if you're not entirely sure, and if you're willing to sacrifice a little performance, it is not unreasonable to leave them there.

Re:printf

[shutdown -p now]

Programmer stupidity (or rather inattentiveness) is not limited to debug code, so why limit asserts to it? Unless you really need that 1% of performance you gain by disabling them...

Re:printf

[shutdown -p now]

Asserts are there to ensure that you do indeed handle all inputs and "process a sane default or abort the function returning an error". If the latter is done, then the assert never gets hit (and there's no need to remove it). But if it's not done, by mistake - i.e. due to a bug - then the assert will ensure that your process dies right there and then, before it can be exploited. It's the last line of defense. Its purpose is not to be user friendly - by the time you get to it, all the code that deals with "user friendly" part of things has already done its job (and failed - which is a bug, but...). Its purpose is to prevent a buffer overflow or a similar exploit vector in buggy code.

Re:printf

[Jorl17]

You're right, the performance difference is negligible. I guess it's just a habit I've developed, though when I come to think of it, it really makes some sense to leave that in release code. OTOH, it might reveal what you expect a function to do more easily, thus facilitating reverse-engineering if one is afraid of that.

Re:printf

[gargleblast]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Whoa there!

1. Don't worry about the harmless. WORRY about the HARMFUL
2. Don't worry about the "not completely unexpected". That is, of course, the expected. WORRY about the UNEXPECTED
3. "your program shouldn't crash" ... thank you Capt'n Obvious. Now quick: think of three things a program can do that are worse than crashing.

Bzzzt. Time's up. Did you get: (1) Have exploitable security flaws; (2) Corrupt or delete data; (3) Hang or livelock. There are others.

Cheers.

Re:printf

[shutdown -p now]

I think I'd worry about security (think dangling pointers and integer/buffer overflows in case your data isn't in a state you expect it to be) before worrying about ease of reverse engineering in pretty much every scenario I can think of. In the end, if someone really cares that much about my code, they will reverse engineer it one way or another - by tracing all the way through the assembly, if necessary. Weaker security, on the other hand, means potential problems for users of my code - i.e. my employer's customers. When you have a lot of customers, that can add up to a major snafu real quick - not to mention the moral responsibility.

Re:printf

[Bomazi]

You don't understand what assert() is for.

It doesn't cause a crash. Quite the opposite. It is a way of deliberately causing program termination upon encountering an internal inconsistency; precisely so as to avoid a crash, a silent failure or some other undesirable behavior.

Obviously, in a bug-free program, assert() would never trigger and is therefore unnecessary. In the real world it is a useful safety net.

Note that assert() is sometimes used to catch runtime errors. That is indeed inappropriate. But you shouldn't condemn the tool because it is sometimes used incorrectly.

Re:printf

[Anonymous Coward]

What's funny about Apple's duplicating efforts and maintaining, at least, two separate code libraries for handling user input ?!

I would have been much happier if this bug have been a part of every Apple product. This would have meant that the company has a set of libraries everyone is using internally and those get worked on by a dedicated team.

Now it means whenever a security flaw is found in an Apple product, the security assessors need to check every one of their products for the same flaw since they can't be sure if fixing the library in the one instance would fix it in the next...

Great job Apple.

Re:printf

[Anonymous Coward]

Asserts in testing are a good thing. Crashes in release are not. Asserts should be removed and you either process a sane default or abort the function returning an error, depending on the situation. That may even trickle up to the top level which may decide to exit gracefully telling the user what the problem was. But you do NOT crash.

You can take the assertions out for a release, FOR PERFORMANCE REASONS _IF_ YOU HAVE COMPLETE FAITH IN THE ERROR HANDLING IN FRONT OF THE ASSERTIONS, it doesn't change the fact that you are never supposed to be out of line with the state the assertion is checking for and past that point you should HOPE to crash and not corrupt data. Do you understand? THE REASON YOU CAN TAKE ASSERTIONS OUT IS BECAUSE THEY DO NOT DO ANYTHING OTHER THAN EXIT GRACEFULLY. If you do not abort the program, you get unknown results, and assertion is for a state you should NEVER be in. The code in FRONT of the assertion is supposed to prevent that, the assertion is a last resort. It is a GOOD thing.

Armchair programmer, GTFO. This is disgusting all this +5 insightful assertions should not "crash" buuuuuulshit on this page. INPUT VALIDATION CODE should not abort, the assertion past that point should ABORT WITH DEBUG INFORMATION, or ELSE, you will CRASH IF YOU ARE LUCKY, or CORRUPT DATA.

Re:printf

[Anonymous Coward]

I've read a number of posts here confirming that this caused various browsers to crash, but I still see several people here insisting that the entire premise is false and that there it hasn't caused any crashes. Are these Crash Truthers just playing a game of picky wording, or are the programs in question actually working properly?

Re:printf

[Anonymous Coward]

Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

Maybe you want to correct the wikipedia article on assertions then, because you are so horribly wrong and sure of yourself, and upmoded that I'm really losing faith in /.

http://en.wikipedia.org/wiki/Assertion_(computing)

It is worth distinguishing assertions from routine error-handling. Assertions should be used to document logically impossible situations and discover programming errors — if the impossible occurs, then something fundamental is clearly wrong. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is unwise: assertions do not allow for recovery from errors; an assertion failure will normally halt the program's execution abruptly. Assertions also do not display a user-friendly error message.

How many brain cells does it take to reason that if an assertion modified the logic of your program, that means removing them changes the logic of your program, which means having them in the first place would have been pointless. The only reason to ever take them out is for performance, because they should NOT EVER change the behavior of a program. That is WHY you CAN disable them. They should exit with debugging information for the DEVELOPER, not the user. Input validation code deals with the user.

This assertion detected a bug in the code in front of it, that's WHAT ITS JOB IS, PERIOD.
The code behind an assertion WILL NOT handle that state.

Re:printf

[Provocateur]

Ladies and gentlemen, I have the dubious honor of introducing the original "Bobby" Tables.

Re:printf

[Anonymous Coward]

>> Note that assert() is sometimes used to catch runtime errors. That is indeed inappropriate.

There is nothing inappropriate about using an assert() to crash a program that detects an "impossible" condition (one believed to indicate a bug) at run-time. Not every bug makes itself statically known at compile time, you know.

Re:printf

[AuMatar]

Then instead of an assert you should have a return error (or throw exception) statement. You should NEVER have an assert that doesn't also cause an error return. That's fucking programming 101- because the asserts WILL be compiled out in release builds, and because crashing could leave the system in an unrecoverable state- you ALWAYS kick the error up to a level that can deal with it.

Re:printf

[AuMatar]

You can remove asserts because your program is NEVER supposed to rely on them. The following code:

assert(foo!=null); //do something

is WRONG. Because it depends on the assert. The correct way to code it is

if(foo == null){
        assert(false);
        return some_error_value;
} //do something

Crashing is NEVER acceptable. And you cannot assume its ever an option in a production system- when you crash cleanup code is not necessarily run, and you can leave the system in an unrecoverable state. Fucking amateur.

Re:printf

[Anonymous Coward]

it's because they went out of their way to include checks for the data they were passing around and one of those checks found something unexpected, and aborted the program, by design. I'm pretty sure this is a good thing.

Yeah. I'm pretty sure "do nothing" is a better failure mode than "abort the program" in nearly every case.

Re:printf

[Omestes]

...it has to do with good programming practices.

If good practices involves planned crashes for innocuous user behavior, I'd hate to see what bad ones are.

Re:printf

[Macman408]

I used to think the same way about kernel panics in an operating system - I thought there was no reason why the system should ever halt. And then I had an OS class, where it was pointed out that halting is a quite valid choice when encountering an error condition that indicates that something has gone fundamentally wrong. For example, if you have an allocation bitmap that tells you what parts of your disk is in use, and what parts are free, it has a checksum, and the checksum is incorrect. It may very well be that the safest thing to do in this case is halt, rather than risk a write making it to the disk and overwriting a block that is in use. The user can reboot, and that will probably be the best way to recover from the error. It might be possible to display an error message, however since the code to display such a message is not often used, it's likely still on the disk (it was either never loaded, or was loaded and then swapped out of RAM). So you might think it's safe to try to read the disk still - but you have to set some state somewhere saying that under no circumstances should you write anything while you try to load this code. But what's to say that whatever state you set is working? Obviously something is broken, your checksum was wrong! And for that matter, if you need to swap something else out to load this new code in, you can't, because you've decided that writes are now unsafe. For that matter, maybe the disk is acting up - maybe it'll interpret a read command as a write, or take some other completely bogus action. Or maybe what you think is your memory-mapped disk is now really the network card, because some CPU configuration registers picked up a bad value. Bottom line; there are definitely good reasons to just stop a program, OS, or whatever when you detect an error that should never happen.

That said, this case is not one of those good reasons.

Re:printf

[Anonymous Coward]

Of course assert() is debugging code. It evaluates the expression UNLESS NDEBUG is defined, that is if NoDEBUG then assert() evaluates to nothing. That makes it a handy testing macro active in debug mode and inactive in release.

Now please turn in your geek and your programming cards. And re-read the above snippet from the man page a few times, it states the exact same thing.

Re:printf

[I kan Spl]

File:/// in the "open location" command in Finder does crash on my Mac 10.8.2

The same also causes a crash in Safari, but only if you type (paste) it fast enough so that autocorrect does not suggest something before you are done typing.

Re:printf

[Too Much Noise]

Programmer stupidity (or rather inattentiveness) is not limited to debug code, so why limit asserts to it?

Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*] And the reason is, if you know you might have unexpected input there are other tools to approach it in release mode: if, switch, exceptions, your own custom macros and so on. Assert is for code that has to evaluate to true, otherwise it's a programming error (for a beginner example, bounds checking for array access). If you're using it for release code it's a programmer error, and if it triggers in release code it means you have an inattentive programmer, a testing problem and a design error. And if it happens in a system library that's used by most programs in your OS ...

[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.

Re:printf

[BasilBrush]

The user never types in a null terminated string.

Bad assumption. You might not intend for the user to type in a null terminated string. But that doesn't mean he can't or won't - depending on the platform. Either because the platform doesn't filter out the ctrl-shift-2 combination, because it's being pasted in, or because it's being piped in.

Classic.

Re:printf

[BasilBrush]

Being a programmer is no great claim here. It's almost expected.

And no, it's certainly not a sign of lazy programming. It's the sign of a bug. Everyone creates bugs, not just lazy programmers. And unit testing doesn't approach covering every eventuality. At best it covers easily predicted bugs and regressions.

Re:printf

[BasilBrush]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

It should be used rather a lot. Every time you believe you know something will always be true, but might break if it wasn't, you should put an assert there.

There's no point putting an IF there, because you can't forsee the case where it will be taken. Likewise an exception - exceptions are for foreseen error states. And ignoring it will result in a harder to find bug if that belief is ever wrong.

It's pretty rare when the bug exists in the assert, rather than the main code. Rarer still when it's an assert that is active in release builds. This is one of those cases. But it doesn't mean that asserts are a bad thing.

Re:printf

[rve]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

It's a hack that should be used extensively - in development code. In the production build, you generally turn on a compiler flag that prevents asserts from being compiled. This is why it's absolutely criminal to put code in an assert that has any side effects whatsoever.

Re:printf

[BasilBrush]

Totally and completely fucking wrong. A well written program should not crash for any reason.

All reasonable length programs have bugs. It's a fact of life.

It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

There is no absolute rule on this. It depends on your local coding standards and it depends on the language and platform you're using. There's lots of well written software with release build asserts in it.

Crashing on an assert isn't the worst thing a program can do. Crashing on something that's not an assert is worse, because you don't get the helpful log error that pinpoints the cause. And causing data corruption is far worse still.

Re:printf

[Anonymous Coward]

It is a way of deliberately causing program termination upon encountering an internal inconsistency; precisely so as to avoid a crash, a silent failure or some other undesirable behavior.

What tosh.

It exits the program without syncing files, closing file handles, performing any clean-up. That's a crash. What state is your data in?

Re:printf

[BasilBrush]

That's only one of it's purposes.

It's general purpose is to give physical form to assumptions in the program itself. It both assures that the assumption *is* always correct past that point, and it documents it.

A novice programmer might say, don't make assumptions. But real programmers make reasonable assumptions all the time. For example if you've just written code to calculate an count, and that calculation can't make a number that's zero or less, then that's a valid assert.

Re:printf

[Anonymous Coward]

At best it covers easily predicted bugs and regressions.

You mean, like known invariants? You know, like those that are checked by asserts()?

You are _checking_ for this invariant. You can and you should write tests that follow different paths to that assert.

Re:printf

[BasilBrush]

Then instead of an assert you should have a return error (or throw exception) statement.

No. Those can only ever be for foreseen error states. If they are not foreseen, then they are no documentable, and therefore the calling code can take no sensible action to react to the error or exception.

An assert is a documentation of something that's always true and will never fail. If it fails, that's a bug, and there's no graceful handling of bugs - if you could foresee them, you would have already fixed them.

The question is whether to only have them in debug builds or whether to have them in release builds too. Contrary to your ASSERTION, asserts aren't necessarily compiled out of release builds. The answer is they go in release builds too if the worst case scenario is data corruption from continuing in an unpredictable state.

None of this is in Programming 101. This is stuff you learn when you've been programming a long time.

Re:printf

[BasilBrush]

Not if the worst case scenario of the assertion not being true is data corruption.

Re:printf

[BasilBrush]

Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*]

There are several categories in which it's not only acceptable, it's the best thing you can do. e.g. High security issues, data corruption, or other user harm. Look it up in Code Complete for example.

there are other tools to approach it in release mode: if, switch, exceptions

No. Those can only deal with foreseen errors. They can't deal with unforeseen errors.

[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.

Checking for a valid URL is a foreseen error, and so shouldn't be an assert. It can be handled reasonably because we've predicted it. That doesn't mean that valid uses for asserts in release code don't exist.

Re:printf

[BasilBrush]

Have you heard of Code Complete? If you're a programmer, you probably should have read it. You should probably have a copy in your bookcase. Go read what it has to say in it's section on Assertions before you post any more ill-informed comments on this thread.

Re:printf

[smash]

If it it an assert thats the entire point. You can't trust the data in ram, you can't trust any file handles you have open, you can't trust anything. So no you should NOT be writing to disk in that situation. The only safe thing to do is terminate.

Re:printf

[smash]

Your apache example is bogus. This is terminating because the program hit a state where data is invalid in a way that the code does not know how to handle. Apache could just throw an error. Yes this is a bug and the code SHOULD handle it. But it doesn't. So the only safe thing to do is terminate because "something is wrong" - we don't know what, and it could be catastrophic for all we know. Continuing to run is dangerous from this point...

Re: printf

[Too Much Noise]

Sure Sparky, you can certainly have unforseen errors. You send a rover to Mars, and the whole computing system is bombarded with high energy radiation in much larger doses than here. Chances of having a bit flipped in a constant go up a bit (depending on your hardware mitigation measures). The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?

There are ways to mitigate depending on how important your whole setup is. Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort. This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen. If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.

Re:printf

[smash]

Of course it is better more return an error - if the programmer has put logic in to handle the situation. However this logic is mixing or broken and the only safe thing to do for the program at is point in the absence of such logic is to terminate. This is a bug, yes. However terminating at this point rather than continuing to attempt to process data that is an unexpected state it extremely dangerous as far as security goes. This is actually good programming practice. Bug happen. Terminating like this prevents them from being exploitable.

Re:printf

[smash]

Gah. Autocorrect. Typing on a tablet with 3G because power is out :-/

Re:printf

[smash]

Crashing/teminating before you are exploited is acceptable, nay - preferable. Fucking amateur.

Re:printf

[Anonymous Coward]

Your apache example is bogus. This is terminating because the program hit a state where data is invalid in a way that the code does not know how to handle. Apache could just throw an error. Yes this is a bug and the code SHOULD handle it. But it doesn't. So the only safe thing to do is terminate because "something is wrong" - we don't know what, and it could be catastrophic for all we know. Continuing to run is dangerous from this point...

No, this is terminated because a URI has a valid capitalized letter in what code (incorrectly btw) expects as a lowercase string. So it's abort()-ing on an unexpected URI input for an untrusted (external program) source. Precisely the same thing, only local instead of remote.

BTW, input validation considering invalid input a catastrophic failure ranks below Chicken Little scared that the sky is falling. Input validation should just reject invalid input with an error of appropriate verbosity, that's its job.

Re:printf

[chrismcb]

It may not be "debugging code" but it should only be run in your debug build.
In your release build, it should either do something else (like say, phone home), or do nothing at all.

Re:printf

[Anonymous Coward]

But there is a difference to the user between being infected by a virus due to following a strange pointer, the program overwriting critical data on disk due to following a strange pointer and all those other strange things that can happen and just crashing.
There are loads of cases where a program crashing reliably is going to be the behaviour most preferable by far.

Re:printf

[smash]

Should yes. But if your input validation code has an error (as this does), the safest thing you can do is terminate. The input validation failed. Yes, it should have caught this. No it didn't and rather than continue on, the only safe thing the app can do is terminate.

Re:printf

[Anonymous Coward]

Oh for heaven's sake. You've just made the assert message useless - and demonstrated you don't know when to use them.

Re:printf

[ebcdic]

However, in this case the only bug is in the assert() call itself. It didn't catch a mistake, it was one.

Re:printf

[Anonymous Coward]

And seat belts should only be used when developing a car; no need to have them in a production vehicle...

Re:printf

[aled]

it is, if the alternative is irrecuperable data corruption.

Re:printf

[Anonymous Coward]

That's a broken design. What if the hardware breaks or your software crashes? Your cleanup code will not run and you continue to have issues even after you restart your application. Clean up code should be OPTIONAL for any robust software.

Re:printf

[edxwelch]

I don't know anything about Mac development build, but on Windows assert() is automatically removed in the release build (that's how assert is ment to work). So, looks more like a broken release build setup, than some one forgetting something.

Re:printf

[Anonymous Coward]

OR maybe his/her methodology was to convert the unknown-cased input to lowercase before comparing (implementing the standard), but somehow faulty code allowed casing to slip by, where it hit an assert.

Re:printf

[Anonymous Coward]

Make it more obvious you're not a developer please.

Re:printf

[ebcdic]

A program can't necessarily fail gracefully. An assertion failing means that something has already gone wrong; perhaps data structures are corrupted and continuing might result in worse damage: writing wrong data, deleting the wrong file. Returning to the caller is not necessarily safer than exiting.

Re:printf

[Bomazi]

assert() doesn't work at compile time anyway.

By runtime error I mean something like an input validation error, an out of memory error, a disk full situation, etc... Basically something that might or might not happen, depending of what happens outside the program during execution.

This is in contrast with a programming error, which could be said to exist before the program starts, and which always happens (when the relevant code runs).

For example, malloc() returning null is a runtime error. Passing a null pointer to a function that doesn't expect it because you forgot to set it, is not. assert() would be an appropriate way to catch the second error, not the first.

Re:printf

[Bomazi]

assert() causes a *deliberate* termination, in the sense that the programmer explicitly intends the program to terminate at that point if the assertion fails.

This contrast with an unintended termination, as caused by something like a SIGSEGV.

assert() doesn't *gracefully* terminate, as exit() would, but that is a separate issue. And it is done that way because the state of the program can no longer be trusted at that point. Of course you might want to have more granularity than just assert() and exit(), but you need something that can do an "emergency stop" in some cases.

Re:printf

[Anonymous Coward]

Assert should be used for "should never happen" cases, like pre/post-conditions.

And the case that this article is about is a pre-condition, namely that the code for handling file:/// URIs is indeed looking at a file:/// URI. It just happens to be a buggy one, in that it does the check case-sensitively.

Re:printf

[Anonymous Coward]

[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.

That's not remotely comparable. A better analogy would be to suppose that Apache checks for a valid URI, returns an error if it's invalid, and otherwise passes the URI on to a handler function, then the handler function assert()s that it has actually been given a valid URI. If the asset triggers then it must be a bug in Apache, it's not something that can be triggered purely externally.

Re:printf

[shutdown -p now]

You don't have to define NDEBUG in release builds, and many people don't.

Also, assert in the C standard library is not the only way to do an assert. You can have your own macro that does things differently. The only thing that all asserts have in common is that they are designed to assert that a certain expression is always true on this particular code path, and indicate a design flaw in the code if they ever fail.

Re:printf

[Hal_Porter]

I like C, but the problem is that most programmers cause chaos when they write it. C was always meant as a language that people who like assembler will like and use and be more productive. It was not meant as a language that today's script monkeys should use.

Also Objective C was designed according to the prinicples of Objectivism - i.e. the code of the looters and moochers would crash and burn and bankrupt their companies whereas the code of Great Men would navigate the formidable obstacles of pointers and demonstrate their status as Nietzschean Ubermenschen and be rewarded with tonnes of cash and Patricia Neal, so this is not really surprising.

Re:printf

[nitehawk214]

What is funnier that file:/// doesn't work.

The Captil F is required. at least in my limited testing.

Typing 'file:///' opened Finder.app from Safari's address bar just fine on my machine.

In this case when GP says "doesn't work" he really means "does work", or rather, "doesn't crash".

Re:printf

[shutdown -p now]

This is terminated because the program did not expect to see an URI with such capitalization, and (presumably) doesn't have code to handle it correctly - leading to an unexpected state where you can no longer be certain of the data. It indicates a bug (they forgot to handle different capitalization correctly, and they forgot to do proper user input validation), yes. But the way it handles that program bug, until such time as it's fixed, is absolutely correct.

Re:printf

[shutdown -p now]

In your release build, it should never be hit. But unless you can absolutely guarantee it, leave it there. You will make mistakes, and it's better to handle them in a safer manner.

If it's hit, your program is in a state that you have not foreseen when writing it. If you're using assert for its intended purpose, then you're claiming: "I expect this condition to always be true here; the following code is written with this assumption in mind". If the condition is somehow not true, then the following code is a bug/exploit farm, and should not be allowed to run. You might also want to phone home, yes (though e.g. on Windows, WER will do it for you if you register for it). You definitely don't want to do nothing.

Re:printf

[AuMatar]

Then his string terminates sooner than the data stream he types. Which won't break anything. The key is you don't rely on the user to enter the terminating null, just like you don't rely on them to enter a length field.

Re:printf

[Jappus]

Based on what you said, the summary title is incorrect. The programs aren't crashing, but rather are ending normally, just not when the user thinks they're telling it to.

It is easy to argue that while this is technically a "normal" shutdown given the code of the program; it is certainly not a normal shutdown given the task and role of the program.

You know: Letter of the law versus spirit of the law.

Your program can only execute the letter of the law (its code), but its true purpose should always be the spirit (its intended role). Otherwise, any bug inside the program would need to be considered as a "normal program exit", as the bug is an inevitable result of its code. Since that is obviously not the case:

This assert being thrown IS a bug, and the subsequent application exit not a normal shutdown. There is nothing to defend here as being "good".

Re:printf

[SanitaryFather]

Cool! Great way to restart apps, no more clicking those pesky little x's.

Re:printf

[Anonymous Coward]

Worse yet: chances are they are using asserts for normal error checking.

Re:printf

[macsoft]

Here speaketh the Apple hater. Its bad because you can crash it if you type something you would never type anyway? "type" Ctrl+Alt+Del on your Windows machine, it will "crash" much worst.

Re:printf

[ScriptedReplay]

That doesn't mean that valid uses for asserts in release code don't exist.

There are no valid cases for assert() in release code. It's about as uninformative as it gets for that. If you really need thosue checks done, put an actual check in place - you know, something that will log/tell you useful information like what invalid value was encountered versus what was expected, a stack trace, and so on. Not just printing out __FILE__ and __LINE__ and expect what, that the customer will have a debugger already attached to the process to pick up the rest of the info a developer would need?

assert() is a debug macro. If you need to test release code then use/write something appropriate for release. Especially something that does not abort() when returning an error code would be sufficient.

Re:printf

[Fulkkari]

Just adding my 2 cents. I agree with you that crashing is never acceptable (as in you have something broken), but a forced exit out of the program through an assertion is the most sane thing to do when the error handling has failed and you have an inconsistent state. The best choice of bad ones so to speak. You should not continue hoping things will turn out good (imagine you were talking about a life critical system), but just exit and avoid further damage and restart the program. You might of course be able to write code to take you out of the situation and fix itself, but that is not assertions then, it is error handling.

Re:printf

[GoogleShill]

You should know that the 'return' statement is exactly what jumps to the shellcode in a stack-based buffer overflow exploit. Asserting and crashing is far more secure than calling 'return' from a potentially corrupted stack.

Re:printf

[niftymitch]

I assert() your assert is bogus. Bogus asserts are brutal and all too common.

Still I also assert() asserts are under used.

Re:printf

[viperidaenz]

When an input does not conform to your method/function/class/procedure's contract, your throw an exception or some other specified error condition in said contract.

You don't blindly swallow it and assume you know the intention of the callers.

Doing anything undocumented will result in subtle errors that manifest themselves in other parts of the system because you're not doing what you said you were going to do.

Re:printf

[viperidaenz]

You don't remove your debugging code. You do what the man page you pasted says - you disable assertions as a compile option. Otherwise next time you do a change, those assertions your removed won't be raised during testing and bugs will slip through.

The only reason to remove assertions in the first place though, is for performance.
The first rule of performance tuning is if a benchmark doesn't show an improvement, don't do it. Easier to read, test and maintain code is more important then a zero gain in performance.

Re:printf

[normangray]

That example is a WRONG use of assert -- you're using assert() as a poor-man's exception.

The right way to code that is

if (foo == null) { // bad state
    return some_error_value;
}
assert(foo != null); // do something which presumes that foo is not null...

Writing an assert in your code is the statement that you have examined your code and believe you have proved that it is _impossible_ under any circumstances, for the assertion to be false -- not bad user input, not a bad call from client code, there are no possible bad conditions you haven't already handled, nothing.

Thus if an assertion evaluates to false, the impossible has just happened. Black is white, gravity points upwards, your computer is an iguana. Your program has (in effect) already crashed, but the world hasn't noticed yet.

So, what do _you_ want to do at this exciting point, in production code? Just carry on with your fingers crossed and see what happens next?

Re:printf

[Hognoxious]

Not when all you're doing is highlighting things that look vaguely like phone numbers or URLs or names of Roman emperors or whatever so some hipster can do something pretentious and useless with one click.

You fucking silently ignore it.

Re:printf

[frisket]

Exactly. And what kind of dickhead types File:/// with a capital F?

I would have been more impressed if the error had been for the right reason: the file:/// URI is essentially a request for an ls -l / which is something the end user probably shouldn't get without authenticating.

Re:printf

[mug funky]

i hope i never need to use a program you've worked on.

Re: printf

[BasilBrush]

The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?

You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.

Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort.

Correct. Lots of reasons for aborting in debug builds, a few reasons for aborting in release builds.

This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen.

Also correct. No one is trying to defend the assert involved in this particular defect, not asserts in general to validate user input. Real my posts, you'll not see any such thing. At this stage the discussion is about whether there is any place for asserts in release builds. You said there wasn't in your previous post. You have now seen the light and accepted that there is.

Sure Sparky... If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.

You're trying and failing to patronise. I've not been programming for just 10 years, I've been programming since 1979. I do know what I'm talking about. I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.

Re:printf

[exomondo]

All reasonable length programs have bugs. It's a fact of life.

But /. always brings out these god-like programmers, they write perfect, bugfree, secure, invulnerable code...of course they never say what this code is or who they are, but they're anonymous people on the internet, why wouldn't you take their word for it?

Re:printf

[BasilBrush]

Then his string terminates sooner than the data stream he types. Which won't break anything.

Another bad assumption. Tricks like these are often used in exploits.

Re:printf

[Anonymous Coward]

Let's get back to the original topic. By simply typing "File:///", why can't I trust the data in ram, why can't I trust any file handles I have open, why can't I trust anything? The answer is, no reason, so why should the program terminate?

Re:printf

[Anonymous Coward]

It is a way of deliberately causing program termination upon encountering an internal inconsistency...

Then this might be a difference of understanding of the word "crash". Programmers like yourself probably have a very strict and well defined meaning for the word. For an average user like myself, if a program exits unexpectedly - whether it was programmatically graceful or not - I would call that a crash.

Re:printf

[Anonymous Coward]

I wrote a number of programs that definetly crash in certain conditions. (It's server programs, so no user ...)
Now before you go nuts. I got 3 levels of failing in these applications:
1. silent, just continue running with the next input with a warning in the logfile
2. loud, send a warning, (through another app) that warns me, put a line in the logfile, then continue
3. crash, make sure someone pays closer attention before we can continue.

Re: printf

[Too Much Noise]

You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.

And you bring this up to justify assert()ing ... fun stuff. Aside from the fact that it's completely irrelevant to the example i gave - which was intentionally far-corner case in that it had a high enough probability of hardware errors, where neither asserts nor design by contract solve anything (the correct answer would have been fault-tolerant computing at hardware level). I'll concede that mine was a poor example, but it did have the redeeming quality of generating an amusing reply.

I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.

Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing. Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished. Feel free to stick to it, but it still makes for bad programming practice. I would advise writing a different piece of checking code that provides more information and has more flexibility in dealing with the error than shutting everything up.

I've not been programming for just 10 years, I've been programming since 1979.

Good for you. I however only want to avoid installing software that i would need now and was produced following dubious coding standards, so that means reasonably recent and 10 years should cover it. Sadly, it's an impossible task in absolute terms, but every little bit helps.

Re:printf

[RaceProUK]

Did you write the code in question? No? Then you have no idea what the internal state is.

Re:printf

[RaceProUK]

I've read a number of posts here confirming that this caused various browsers to crash, but I still see several people here insisting that the entire premise is false and that there it hasn't caused any crashes. Are these Crash Truthers just playing a game of picky wording, or are the programs in question actually working properly?

Most of the argument is about crash vs immediate termination. An assert failure generally triggers the latter. From a user POV though, they're identical.

Re:printf

[Anonymous Coward]

You sound like one of the google/Android engineers who thinks its ok to autogenerate android hostnames that include invalid characters.

AC

Re:printf

[Anonymous Coward]

So you're saying that anytime file:// is typed in any textbox in any program (even if it isn't intended to be interpreted), it shouldn't be capitalized or the program should bail? That's nonsense, and this whole problem exists because of liberally scattered ill-considered asserts.

Re:printf

[Anonymous Coward]

"...An implementation should..."

Apparently you need to learn the difference between 'should', and 'shall'. They actually have different meanings, and are defined in a particular way for IETF documents.

Of course, based on the described behavior in this case, it could be as simple as a missed 'ToLower' call in the assert code path.

Re:printf

[Anonymous Coward]

An assert may *look* like a crash to an end user, but it isn't actually a crash. A failed assert will run any properly registered cleanup code.

Fucking amateur.

Re: printf

[BasilBrush]

I'll concede that mine was a poor example

Indeed it was, but it gave me an opportunity to point out that asserts don't need to be ad-hoc, but there is an available methodology.

Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing.

Assertion macros. Plenty of platforms already have them defined. If not define them yourself. Then you can put in the assert anything you can put in a printf. You're advocating coding out an assert long hand each time. Foolish.

Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished.

If you're not in charge of the build flags, then define your own release assert macro that doesn't get switched off by a flag. Not using asserts because someone else might break the build is irrational.

Clearly you believe that there should never be asserts in release builds. It's fine for you to believe that and for you to have that as a personal rule. However what you think is not the definition of good practice. There are plenty of scenarios where asserts in release builds are the right thing to do.

The ironic thing is that what you do think is OK for release builds is what's already in the assert macros on both of the platforms I've worked on in the last 10 years.

I think perhaps you just wanted an argument. Even if it made no sense.

Re:printf

[Anonymous Coward]

No. Those can only deal with foreseen errors. They can't deal with unforeseen errors.

You keep saying that (ad nauseum ... for the love of Zod, please, just say your piece and move on), but I'm having trouble convincing myself that you know what you're talking about.

If you put in an assert to test for the error condition, YOU FORESAW THE ERROR.

Re:printf

[YodasEvilTwin]

If it wasn't foreseen there wouldn't be an assert. If asserts were placed everywhere something unforeseen could happen then they would be, well, everywhere.

Re:printf

[BasilBrush]

If it wasn't foreseen there wouldn't be an assert.

That's not true at all. In fact it's the opposite of the truth. Asserts go wherever there is an assumption of an invariant. They don't go where you can foresee that something might not be invariant.

If asserts were placed everywhere something unforeseen could happen then they would be, well, everywhere.

They can indeed be very frequent. It depends. If you want a methodology for it, look at programming by contract. That would limit you to putting asserts on pre-conditions and post-conditions of routines.

Re:printf

[Anonymous Coward]

one of key reliability principles in Erlang programming is 'let it crash' (and be restarted by supervisor). You don't want your code to live with escalating erroneous condition.

Apple's response

[Anonymous Coward]

You're doing it wrong.

no big deal.

Steve

Re:Apple's response

[radiumsoup]

damnit, I just ran out of mod points, too... +infinity for you.

Re:Apple's response

[Anonymous Coward]

You can't use your left-hand.

Re:Apple's response

[girlintraining]

Steve is in the iCloud now. Someone tried turning him off and then back on again. In an appeal to hipsters, he's gone underground to sell more macs. He is permanently 404. There is no way he could have had anything to say about this. There is no app for that. Get it? :P

Re:Apple's response

[dugancent]

My response:

Steve is dead and has been for over a year. Time for some new jokes.

Re:Apple's response

[Anonymous Coward]

Like the Monty Python parrot sketch, except entirely devoid of humour.

Re:Apple's response

[Anonymous Coward]

File:/// (typed into safari)

Re:Apple's response

[Anonymous Coward]

Time for some new jokes.

But Mountain Lion is the latest!

Re:Apple's response

[Anonymous Coward]

except no one reacted hysterically. i guess you're just seeing whatever you want to see, huh? interesting character trait, that. mainly points to you being socially retarded.

Re:Apple's response

[Drgnkght]

The humour is just pining for the fjords.

Re:Apple's response

[Anonymous Coward]

I practically died laughing at "Steve is in the iCloud now". Thank you. I'm not sure why you were voted a troll, but I believe they meant hilarious =).

Re:Apple's response

[Anonymous Coward]

Steve has gone dark in the iCloud. He now takes 30% of everything. EVERYTHING. If you want a better world, suck it up man. Tough luck. You can't change it. There is no appeal process. No customer service. The APIs are changed. There is no going back. The only choice is iForward. Find your own iCloud. Find your own app store. This one is his, it looks like many others, but this one is Steve's. Your only option is to make a new app and play again.

Re:Apple's response

[node 3]

Maybe they'd be less hostile if you stopped calling them "fanbois"?

Re:Apple's response

[jrumney]

Indeed, they already released a fix for it. It's called iCloud. Keeping things in the privacy of your own disk is now officially a bug (soon to be reclassified as user error).

BRB

[AmiMoJo]

BRB, heading down to the Apple Store...

Re:BRB

[drcagn]

Typing the string has the same effect on the app as quitting the app. So.... have fun going to the apple store and quitting the apps.

Re: BRB

[rsmith84]

Not without a Genius Bar appointment you're not!

Re:BRB

[Anonymous Coward]

I wish I knew how to quit you.

Re:BRB

[drcagn]

I know, I can be dangerously addictive sometimes.

Re:BRB

[93 Escort Wagon]

I wish I didn't have to type "whoosh"...

Re:BRB

[Anonymous Coward]

You missed the counter-whoosh

Re:BRB

[Tablizer]

heading down to the Apple Store...

Reminds me when I was teen at the mall before the PC era, I'd see a computer on display in the store and type in:

10 PRINT "RUN, COMPUTER WILL EXPLODE!"
20 GOTO 10
RUN

Re:BRB

[YttriumOxide]

Typing the string has the same effect on the app as quitting the app. So.... have fun going to the apple store and quitting the apps.

Exact behaviour seems to depend on the app. Just tried it here and:

TextEdit: Prints the final /, hangs for a long time, then shows "quit unexpectedly" dialog
Safari (text box on webpage): Does not print the final /, hangs the tab indefinitely, tries to allow continued usage of Safari (in other tabs), but data won't load, and already open tabs when scrolled contain large "grey" spaces instead of further content.
Safari (address bar): Prints the final /, hangs for a short time, then shows "quit unexpectedly".
Notes (content of note): Prints the final /, hangs for a long time, then shows "quit unexpectedly" dialog
Notes (name of new note): Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog
Preview (search field): Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog

I assume the "Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog" behaviour is the "immediate quit" of the assertion failure, however things like Safari's behaviour are clearly a process within the app terminating without the app itself being terminated.

Re:BRB

[AmiMoJo]

It produces a nice exception error message. Perfect for making Apple fanbois who claim that Macs never crash look like twats.

Re:BRB

[AmiMoJo]

Back at school when I was about 10 we argued for weeks over the meaning of an "illegal operation" error message, and if the poor child who was using the computer at the time was going to jail.

Re:BRB

[caseih]

No it doesn't. Applications crash all the time in OS X, Windows, and Linux. No fanboi will claim otherwise unless he's really stupid. And that has nothing to do with Macs never crashing or Linux never crashing. In fact a system crash in MaOS *is* very rare. Certainly much rarer than it was in Windows XP, which was the dominant OS when MacOS came to be and the Mac fanbois got all excited over it. Now I think even the most diehard fanbois have to admit now that Windows is pretty darn stable.

Android, now that's another story, though in Android's case it's not the OS crashing either, it's the Android environment triggering a reboot when it freezes, which irritates me to no end. Why can't Android just restart the environment? Why does it have to reboot Linux kernel?

Re:BRB

[ahabswhale]

It's the app that crashes, not the OS but lets not let facts get in the way...

Re:BRB

[Anonymous Coward]

Why? This bug doesn't crash any Macs.

Re:BRB

[Anonymous Coward]

No it doesn't. Applications crash all the time in OS X, Windows, and Linux. No fanboi will claim otherwise unless he's really stupid.

Re:BRB

[Anonymous Coward]

I assume the "Prints the final /, hangs for a very short time, then shows "quit unexpectedly" dialog" behaviour is the "immediate quit" of the assertion failure, however things like Safari's behaviour are clearly a process within the app terminating without the app itself being terminated.

When a program dies, the hang followed by the "quit unexpectedly" dialog is Apple's crash reporter tool collecting information, then presenting UI to tell you something bad happened. There's a preference somewhere which disables automatic crash reporting, in which case the reporter still runs, but you get extra UI in the "quit unexpectedly" dialog letting you review the crash report and choose whether to send it to Apple.

And you're right about Safari. For security, they've moved all HTML/CSS/JS interpretation into a heavily sandboxed child process named "Safari Web Content". If you type into the address bar, your input is going to the GUI shell, which crashes and takes down its child in the process. Type into a web form, and you're crashing the Web Content process instead. The GUI can keep on going, but anything which depends on communication with a live Web Content process (e.g. rendering revealed areas when scrolling) will not work.

(The odd thing there is that it's not detecting its child going away and subsequently spawning a new Web Content process. It usually does that.)

Powerpoint summary of TFS

[TapeCutter]

- An obscure library bug triggered by a magic string.

- In the latest version.

Re:Powerpoint summary of TFS

[jonadab]

> An obscure library bug triggered by a magic string.

The thing is, the magic string in question is not particularly obscure. Any app that normally handles URLs is fairly likely to get that typed into it at some point. Okay, granted, protocols are usually not capitalized, and File:/// is no more common than Http:// or Mailto:, but nonetheless, this is something people are definitely going to run into occasionally.

(Yes, file protocol terminates the protocol with just two slashes; but, importantly, the next segment of the URL is an absolute path. So while the third slash would be a typo on a multi-rooted system like Windows or VMS, it's pretty much mandatory on a single-rooted system that uses slash as a directory separator -- like, say, anything with Unix underpinnings.)

Re:Powerpoint summary of TFS

[Anonymous Coward]

That's no PowerPoint. Where are the annoying sound effects or the flying text or the animations. Someone needs to go back to Using Office 101.

Re:Powerpoint summary of TFS

[oakgrove]

Just a thought, using something like vnc from a mobile device would make it more likely to happen since keyboards on most smartphones/tablets capitalize the first letter in anything it thinks is a sentence.

Re:Powerpoint summary of TFS

[Anonymous Coward]

(Yes, file protocol terminates the protocol with just two slashes; but, importantly, the next segment of the URL is an absolute path. So while the third slash would be a typo on a multi-rooted system like Windows or VMS, it's pretty much mandatory on a single-rooted system that uses slash as a directory separator -- like, say, anything with Unix underpinnings.)

Actually, the third slash means "this computer" and is required on Windows too. You have to write "file:///C:/..." on Windows to get anywhere. So no, it isn't a typo.

Re:Powerpoint summary of TFS

[BasilBrush]

but nonetheless, this is something people are definitely going to run into occasionally.

Looks like a very embarrassing bug to me. But it's taken 6 months for anyone to spot it. So, surprising though it may seem, the chances of any one individual ever getting it accidentally are slim.

(Intriguingly the third slash it not necessary. Typing random letters after 2 slashes also tends to crash it. It just takes a few more. It'll be interesting to get the diagnosis of exactly what's going on here.)

Re:Powerpoint summary of TFS

[DarwinSurvivor]

I'm actually curious if clicking a link to File:/// will crash one. Any mac users want to try it and (after possibly restarting their browser) report the results? Note: slashdot changes File to file, so you might have to try a local html file.

Re:Powerpoint summary of TFS

[adolf]

Actually, the third slash means "this computer" and is required on Windows too. You have to write "file:///C:/..." on Windows to get anywhere. So no, it isn't a typo.

[citation needed]

On my computer (Windows 7), in Windows Explorer, these all work the same:

file://C:/
file:///C:/
file:////////////////C:/

These also work the same:

file://
file:///
file:////////////////

Re:Powerpoint summary of TFS

[Anonymous Coward]

Microsoft software accepting something that isn't valid according to the spec? Say it ain't so!

Re:Powerpoint summary of TFS

[marcansoft]

Clicking a link to a page containing a textbox containing File:/// will. So this is also a remote DoS for Safari.

Re:Powerpoint summary of TFS

[Anonymous Coward]

I put that in my address bar and it crashes the browser

Re:Powerpoint summary of TFS

[Anonymous Coward]

Firefox on Linux interprets all of the following as "show the root directory":

file:
file:/
file://
file:///
file:////////////////

The first three of those are invalid since colon double-slash is a separator required as part of a valid URL. In fact, Firefox just silently promotes all three of them to the fourth, clearly assuming you meant to do that instead. The fifth one with a ton of slashes is displayed as a ton of slashes, because in normal UNIX path specifier rules that's a perfectly valid way of referring to the root of the FS (try 'ls ///////', it will work).

Re:Powerpoint summary of TFS

[jonadab]

> Actually, the third slash means "this computer"
> and is required on Windows too.

If the third slash meant "this computer", single-rooted systems would require a fourth one to indicate the filesystem root. Such is not the case.

Little light on specifics....

[Kenja]

Tried this in every app I could think of and have had no issues (TextEdit, Komodo, iCal, Eclipse, Libra Office, Chrome, FireFox). Not calling shenanigans, but a specific example would be nice.

Re:Little light on specifics....

[Anonymous Coward]

Are you sure? "file:///" works fine, but "File:///" does not.

It's case-sensitive.

Re:Little light on specifics....

[Kenja]

Ah, did manage to replicate it. Despite what the long article says, it does seem to be case sensitive. Very odd bug. The truly worrisome thing is that this would seem to indicate that even the most basic of text editors is capable of running scripts from plain text (as opposed to apple script). Not sure what the ramifications of that are, but it seems like a potential vector for malware.

Re:Little light on specifics....

[Anonymous Coward]

Case seems to matter. I was able to crash Text Edit, and then the Crash Reporter too.

Re:Little light on specifics....

[Anonymous Coward]

Ah, did manage to replicate it. Despite what the long article says, it does seem to be case sensitive. Very odd bug. The truly worrisome thing is that this would seem to indicate that even the most basic of text editors is capable of running scripts from plain text (as opposed to apple script). Not sure what the ramifications of that are, but it seems like a potential vector for malware.

Obviously someone left something open in a call to Data Detectors. Should be really easy to find and fix though. Most likely it causes some kind of buffer overload thus killing the requesting process which is the requesting application.

Because the coding for OS10 is a C variant, the call is case sensitive, same as all unix like systems. This is not something that is at all akin to an apple script.

This is not the same thing as crashing the shit out of Linux with a simple shell script fork bomb. But it does not surprise me that an overload can take place with a call to a function in Mac OS, I am sure it will be fixed and quickly. However, I doubt that it can be exploited in the same way some Microsoft software faults usually can.

Not that OS10 is that great, but at least there are reasonable safeguards at the user level against writing to /root from user level programs, and file overloads cause the OS by default to terminate applications instead of just hanging the system and leaving a buffer open! Which is the way some very sophisticated malware goes after similar Windows OS calls that can be hacked.

Re:Little light on specifics....

[Assmasher]

I just crashed it in 10.8.2 by simply typing it (exactly as specified) into the document area in TextEdit.

Re:Little light on specifics....

[Anonymous Coward]

Yeah, sure, really worrisome, but not as much as your definition of code execution..l

Sir, i will have to ask you to step away from that keyboard slowly...

Re:Little light on specifics....

[93 Escort Wagon]

Interesting - it's fairly reproducible in programs that take a URL, but, unlike what some of you are claiming, it's not crashing anything for me when I type it somewhere else (e.g. In an open document window in BBedit, in the Google search box in Firefox). When I tried it in TextEdit's search box, it (sorta) crashed It... Actually, while it killed the active window, it left the program itself running.

Re:Little light on specifics....

[cheesybagel]

Let me guess. The Google search box in Firefox was not implemented using Apple's Cocoa widget Framework.

Re:Little light on specifics....

[Assmasher]

I was surprised, maybe it's a spellchecker or something - I never use TextEdit but just opened it up, typed in the File:/// and after about 1/4 of a second the window disappeared and I got "TextEdit quit unexpectedly." with the standard Ignore|Report...|Reopen buttons...

Just double checked - same result.

Strange.

Re:Little light on specifics....

[93 Escort Wagon]

Let me guess. The Google search box in Firefox was not implemented using Apple's Cocoa widget Framework.

Yes, of course - but the claim was that simply typing this magic string could crash just about any program in Mountain Lion.

Re:Little light on specifics....

[Anonymous Coward]

If you type File: then wait 4 secs then add the /// it does not crash. But if you type it quickly it does. Tested in Text Edit. Spell Check? Or Auto Save?

Re:Little light on specifics....

[Anonymous Coward]

According to stack trace, spell check leading into the data detectors.

Re:Little light on specifics....

[SilverJets]

Tried this in every app I could think of and have had no issues (TextEdit, Komodo, iCal, Eclipse, Libra Office, Chrome, FireFox). Not calling shenanigans, but a specific example would be nice.

Try typing it into the URL field in Safari.

Re:Little light on specifics....

[Anonymous Coward]

That's not very interesting.

Re:Little light on specifics....

[Twinbee]

Wouldn't that slow programs down anyway - constantly checking the input like that? How ugly and inefficient.

Re:Little light on specifics....

[Twinbee]

How about if you try pasting it in?

Re:Little light on specifics....

[Alioth]

The set of "just about any program" is smaller than the set of "all programs". So the claim is entirely true. Yes, just about any program will crash if you type the magic string and just because Firefox is outside of the set of "just about any program" doesn't make it any less true. Firefox is somewhat of an oddity by being a Mac app that doesn't use the Apple framework. Most do.

Re:Little light on specifics....

[Anonymous Coward]

Macs don't have malware.

Re:Little light on specifics....

[scarlac]

The bug requires Text Replacements to be enabled. It is enabled by default (but I disabled it because it's annoying). When enabled, I was able to reproduce the bug in iCal and Chrome but not TextEdit (where my default mode is plain text).

Re:Little light on specifics....

[Anonymous Coward]

"Almost any" != "all programs"

Re:Little light on specifics....

[petervandervos]

Tried this in every app I could think of and have had no issues (TextEdit, Komodo, iCal, Eclipse, Libra Office, Chrome, FireFox). Not calling shenanigans, but a specific example would be nice.

Try typing it into the URL field in Safari.

Not only the URL, but also a search field of any (sorry, a lot) of programs will crash the program. Clearly whenever the OS evaluates a string it will crash so URL's, search strings and even when the spellchecker kicks in. I even can not type the string in this Comment field (spellchecker). Also noted that it is not File etc, but any permutation of file with a capital letter in it so File, filE, fILe etc.

You're doing it wrong

[greggman]

No one should ever need to type file:///

There are no bugs. You're doing it wrong

Re:You're doing it wrong

[Anonymous Coward]

The lowercase version doesn't cause a crash, so your claim is irrelevant.

Re:You're doing it wrong

[Vreejack]

That was sarcasm, right?
Anyway, I have twelve examples of file:/// in my browser history, all of them automatically generated by scripts. If I ever meet a script that capitalizes "File" then we may be in trouble.

Re:You're doing it wrong

[sjames]

Maybe he's using a Mac. The first two times he tried that message, Safari crashed.

Re:You're doing it wrong

[Anonymous Coward]

You are full of shit. Nothing a user types should ever crash a program. There is no way "you're doing it wrong" just by typing Latin alphanumerics and it takes one hell of an arrogant programmer to claim otherwise.

Re:You're doing it wrong

[Anonymous Coward]

You moron. It's a joke referencing the iPhone. Remember? If you hold the phone the "wrong way" it won't work because your hand is covering the internal antenna.
That was 100% Apple's fault, but they blamed the user saying essentially "you are holding it wrong."

Re:You're doing it wrong

[Anonymous Coward]

No one uses Safari. Chrome or die!

Re:You're doing it wrong

[Sigg3.net]

Yeah. Two // 's should be enough for anyone.

donotwant

[Anonymous Coward]

a feature that lets apps recognize dates, locations, and contact data, making it easy for you to save this information in your address book and calendar."

Sounds like a disaster to me.

Re:donotwant

[node 3]

It's kind of fantastic, actually. Someone sends you an email saying, "let's meet for lunch tomorrow", or "my new phone number is ...", etc., and these become clickable to enter a calendar appointment, or address book entry, etc.

These trace back to the Newton, and were a huge part of that device's "magic". And when you get an email with a UPS tracking number as plain text (instead of a hyperlink), and it becomes clickable and asks if you want to track your shipment, you get one of those, "oh, now that's cool!" moments.

Google does something similar in search results. If you put in a UPS tracking number, the top result is for you to track the shipment, etc.

Sure enough

[DaMattster]

I tried it for myself with Google Chrome and Firefox and File:/// does crash the software. Very interesting!

Re:Sure enough

[Anonymous Coward]

10.8.2 here, and file:/// did not crash Google Chrome but File:/// did crash it. Did not try any other app.

Re:Sure enough

[BasilBrush]

Even more interesting is that fact it didn't prevent you from making that post.

Re:Sure enough

[SilverJets]

No crash in Firefox for me but it took down Safari.

Re:Sure enough

[Anonymous Coward]

...Who says he did it using those browsers/platform?

Way to be a mactard!

Re:Sure enough

[Anonymous Coward]

Or he posted from a mobile device or something.

Re:Sure enough

[Anonymous Coward]

Even more interesting is that fact it didn't prevent you from making that post.

He posted using Internet Explorer.

Re:Sure enough

[StripedCow]

Does it also crash your browser if you click this link?

click here please

Re:Sure enough

[Mex]

Firefox didn't crash for me, for what it's worth. I did type it with a capital F.

I managed to crash a couple other apps I wasn't using, including the Finder, so it's an interesting bug, although kind of silly how the summary blows it up.

Security hole?

[Billly Gates]

THe only difference between a crash and an exploit is one has control when the app leaves the bounds of its ram addresses. Since MacOSX apps have access to file:/// in strings that can leave the control of the app then logic would dictate someone could do a file://sh grep -i .../etc/host cp malware.BAD .../etc/host or something stupid.

I do not own a mac so I do not know. Maybe another slashdoter who owns one who is more intuned with where critical files and services are can try to do execute something with it?

Either way this is not good at all and poor exception handling of some of the string apis.

Re:Security hole?

[pushing-robot]

It's not a buffer overflow or anything like that. Some address-reading library happens to have a sanity test that makes a naive assumption; when it catches a file URL, it tests the prefix against the string 'file://'. When the strings don't match (because of a simple case difference) the sanity test fails and the program is shut down. Oops.

It *is* a dumb bug (aren't they all?), but I doubt it could anyone could make a remote code exploit out of that.

Re:Security hole?

[John Hasler]

> I doubt it could anyone could make a remote code exploit
> out of that.

Perhaps not that precisely but what else is that library call (or whatever it is) doing that might be exploitable?

Re:Security hole?

[Your.Master]

Possibly anything, but I don't think this assert is indicative of it doing anything else that might be exploitable. If anything, the overactive assert makes it less exploitable.

The one thing I can think of, is if this assert was in a function that shouldn't have been called at all, so this tips off black-hats into seeing that an exploitable codepath is being taken in a situation where it shouldn't have been taken in the first place.

But I'm guessing it's not doing anything with this string, just doing some kind of type-detection and then exploding, so there wouldn't be any indication of anything exploitable.

Re:Security hole?

[Billly Gates]

What type detection would accept a file:/// for the argument?

It makes me wonder what other arguments are there and the most important question, why can you even do this?!

If I had a Mac I would do some dictionary terms in a script to see what happens. It probes my curiosity.

Re:Security hole?

[Megane]

What type detection would accept a file:/// for the argument?

The type that says "Ooh this looks like a URL, let me change it into a pretty underlined blue for you!"

Re:Security hole?

[Anonymous Coward]

Perhaps not that precisely but what else is that library call (or whatever it is) doing that might be exploitable?

So let me get this straight. There's no sign that this bug is exploitable, but you're all up in arms that the library is "doing" something and panicing that something that it's doing might be insecure? And you don't think that such a catastrophic problem might be equally present in all software?

Running Mountain Lion....

[Anonymous Coward]

didn't kill chrome, didn't kill finder, didn't kill iTunes

What am I doing wrong?

Re:Running Mountain Lion....

[Raistlin77]

It kills Chrome if typed into the address bar and it kills Finder and iTunes if typed into the search. It is case sensitive - File:///

Re:Running Mountain Lion....

[Nerdfest]

Giving money to Apple.

Re:Running Mountain Lion....

[flimflammer]

You were typing file:/// instead of File:///

Re:Running Mountain Lion....

[Frankie70]

You are holding it right. The others aren't.

It Works

[presspass]

I've tested it in several native apps, (Reminders, Textedit, Preview) and in Adobe Acrobat Pro 9.

Find a text input field, even in preferences and it crashes. Bizarre!

OSX 10.8.2
Build 12C3103

Re:It Works

[Anonymous Psychopath]

Spotlight, too.

Re:It works

[Anonymous Coward]

It recovered fully in about 30 seconds though.

Thank god.

How often does a Mac user type this?

[Anonymous Coward]

It seems like a harmless bug, rarely would a Mac user have to type File:///

(wait, I typed File:/// and it did not crash Firefox).

Re:How often does a Mac user type this?

[jonadab]

> rarely would a Mac user have to type File:///

I admit, it is a bit odd to see it capitalized like that.

> (wait, I typed File:/// and it did not crash Firefox).

It probably has to be at the very beginning of a text-entry field.

(I'm just guessing, based on what "file:///" means. I can't test this one myself, as I don't have a Mac here, and the Mac I have access to at work is running Snow Leopard.)

Re:How often does a Mac user type this?

[gnasher719]

> rarely would a Mac user have to type File:///

More people probably did this within the last hour than in the total history of MacOS X before :-)

Not really joking. If many people had done this, then the problem would have been found a lot earlier.

Re:How often does a Mac user type this?

[Anonymous Coward]

And yet still someone did it. Also, someone could have done it and not had the sense or understanding to report it previously.

So?

[Bogtha]

First off, itâ(TM)s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. Thatâ(TM)s not exactly good news given that this is the latest release of Appleâ(TM)s operating system, which an increasing number of Mac users are switching to.

Talk about over-egging the pudding. You're talking as if it's a fundamental flaw that ruins the whole operating system. It's a bug. Of course it's not good news, but it's not certain doom for Mountain Lion either.

Re:So?

[93 Escort Wagon]

Speak for yourself - I just rolled back to Tiger!

Re:So?

[VortexCortex]

First off, itâ(TM)s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. Thatâ(TM)s not exactly good news given that this is the latest release of Appleâ(TM)s operating system, which an increasing number of Mac users are switching to.

Talk about over-egging the pudding. You're talking as if it's a fundamental flaw that ruins the whole operating system. It's a bug. Of course it's not good news, but it's not certain doom for Mountain Lion either.

Oh yeah? Well, this link says otherwise.

it would if slashdot wasn't lowercasing the protocol, but you get the point.

Now, to use some JavaScript or HTTP Redirects to auto-load that URL, and have some REAL fun.

The cause, and a fix

[rsteele19]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

Re:The cause, and a fix

[93 Escort Wagon]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

Yeah, THERE'S a good idea - apply a binary patch from some random post on Slashdot!

Re:The cause, and a fix

[EmperorArthur]

Thanks for the advice, too bad I'm going to ignore it.

I'm going to go out and buy a mac, and then I'm going to find the software with this bug, then I'm going to follow the directions that straight up say not to do so.

On a more serious note, It's always nice to see someone find the problem, and offer a workaround.

I've never heard of data detectors before. It's an interesting idea but also scary. I'm a big fan of sandboxing, so I seriously hope that this is just some function in a library and the OS isn't pawing over every text box.

Re:The cause, and a fix

[Anonymous Coward]

Apple are about to use this patch for their patch......

Re:The cause, and a fix

[Tablizer]

Whaddya mean? It fixed my Goatse screensaver just dandy.

Re:The cause, and a fix

[Anonymous Coward]

Sounds like a fantastic idea!

Actually, I think the point is to understand the issue, not to blindly install a patch that says, right on the tin:

> ____Don't actually use this____. This is just for entertainment.

Re:The cause, and a fix

[Anonymous Coward]

No reason for you to trust me, but I understand assembly and all he is doing is jumping past an assert so as to not trigger it. It is a brute force hack and does not fix the actual problem. Still, applying this patch will stop the crashing.

Re:The cause, and a fix

[Anonymous Coward]

Always backup the original. I'm a random slashdotter armed with IDA Pro.

Re:The cause, and a fix

[Anonymous Coward]

There is no explanation of the cause here and it is certainly not a fix, just an observation of the faulty behavior. This is a binary patch with yet unknown consequences. That is not to say that this person did something completely wrong here or shouldn't get props for the technique but I would advise most not to go around "fixing" things on their operating system like this from things posted on GitHub.

Re:The cause, and a fix

[phantomfive]

You can read the patch first, like the rest of us, right?

Re:The cause, and a fix

[Anonymous Coward]

Also, to what others say, if you take a look at his github (and related webpages) you will see Landon Fuller knows what he is doing. Check it yourself, it's there.

Re:The cause, and a fix

[toddestan]

What are you talking about? It's for Macs, and Macs don't get viruses!

Re:The cause, and a fix

[aquabat]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

^this. The bug is in the assert() statement itself, not in the program logic. Assuming that input validation code exists and was already run before this point, the purpose of this assert() seems to be to make sure the validator is actually doing its job properly. However, the test in the assert() itself is incorrect, since it disallows mixed case file URLs, which are valid, according to spec. Of course, if this assert() statement is his validator, then he's doing it wrong. Big time.

No, It Doesn't

[reallocate]

Thoroughly current Mountain Lion on a Macbook Pro here. When I enter "file:///" into apps, I get directory listings, not crashes.

Re:No, It Doesn't

[H0p313ss]

Crashes textedit

Re:No, It Doesn't

[Anonymous Coward]

The bug is case sensitive; as the bug report says "The capital 'F' is important."

Please do not bother posting something so quickly, without looking into it.

Re:No, It Doesn't

[Anonymous Coward]

It is case sensitive ... the f must be in caps.

Re:No, It Doesn't

[HJED]

It's case sensitive.

Re:No, It Doesn't

[scream at the sky]

correct, It crashed Chrome, Safari, itunes and text edit on my MBP w/ ML, but the F does have to be capitalized.

Re:No, It Doesn't

[H0p313ss]

Crashes Safari (address bar)

Re:No, It Doesn't

[pushing-robot]

Technically, any capitalization other than 'file:///' will do it. File, fILE, or FILE all have the same effect. The problem is the code compares the string to 'file://' without converting to lower case first...oops.

Re:No, It Doesn't

[gnasher719]

Technically, any capitalization other than 'file:///' will do it. File, fILE, or FILE all have the same effect. The problem is the code compares the string to 'file://' without converting to lower case first...oops.

Some code has figured out that the user entered a file url. A sanity check (badly programmed) figures out (wrongly) that it is _not_ a file URL. That wouldn't be a problem; I would have coded it so that something that looks like a file url but doesn't pass sanity checks is just not a file url. The problem is that this code throws an exception that isn't caught.

A note to C++ programmers: Convention in Objective-C is that exceptions are thrown to indicate programming errors. Exceptions are not handled by catching them, but by fixing the code that causes the exception to be thrown. So this sanity check shouldn't have thrown an exception.

Re:No, It Doesn't

[Anonymous Coward]

Cannot get this to crash anything on my 10.8.2 - FF, Chrome, Safari, text edit, pages, etc.

Re:No, It Doesn't

[Anonymous Coward]

Case sensitive. Idiot.

Re:No, It Doesn't

[Volguus Zildrohar]

I had the same problem, but apparently it relies on spell check being enabled (and case sensitivity, as so many keep pointing out). Turn off the spellchecker and there's no problem.

Also, learn to spell, in case it's not fixed quickly :)

Not happening for me

[shatfield]

Running OS X 10.8.2 here, and I tried it in TextEdit, Mail, and Safari.. no crash.

Re:Not happening for me

[Assmasher]

Running 10.8.2 here also and it crashes in TextEdit when simply typing the text into the document - LOL!

Re:Not happening for me

[shatfield]

Just to be sure, I type file:/// into TextEdit or a new Mail message or whatever and it's supposed to crash?

Re:Not happening for me

[tepples]

It is if any of the four letters is capitalized.

Re:Not happening for me

[shatfield]

Ah yes, caps is da bomb ;-)

Ok, now I feel like I'm part of the in crowd again LOL

Re:Not happening for me

[Assmasher]

Not file:/// you must type File:/// and it vanishes with a crash dialog for me.

I literally just run TextEdit and type File:/// and 1/4 second later it vanishes and I get the "quit unexpectedly" dialog ;).

Must be a spell check/URL converter (like Word/Outlook does.)

BTW, crashes Notes when you put it in the search box, but not in the note text area.

Re:Not happening for me

[blackraven14250]

No. It needs to be File:/// or fILe:/// or any other weird capitalization.

Gödel Lives!

[Sam Williams]

http://kleinschmidt.wordpress.com/2006/07/03/i-cannot-be-played-on-record-player-x/

Similar feature in Windows

[clickety6]

We have some text files from a Unix system named aux.something Trying to copy them or open them in Windows causes the whole system to grind to a halt.

Re:Similar feature in Windows

[Anonymous Coward]

What application and Windows version?

Re:Similar feature in Windows

[tragedy]

This is probably because of windows problems with old DOS devices: AUX, CON, PRN, COM1, LPT1 Using them in file names can cause all kinds of weird Windows issues even now. There used to be a spectacular Windows issue that affected just about any program that could interpret a URL. URLs containing a combination of the above device names separated by backslashes (or slashes) could cause a windows machine to crash or hang if the machine tried to parse a URL. Naturally, people would send other people links in e-mail and instant messaging programs with such URLs which would, depending on the program, cause a freeze or bluescreen on clicking, or even just on receipt. Sigh. Good times. Good times. I think there are still a few instant messaging programs that will mysteriously edit out anything you try to send with any of those combinations of letters in combination with a slash, even if it's not a combination that would cause a crash. DragonCon/NASFiC, for example, might do it.

Re:Similar feature in Windows

[Anonymous Coward]

Ah yes, the con/con exploit. Most annoying on AOL as you could specify file names to play sounds in the chat rooms. {S C:\nul\con\con just type into AOL chat in the 90's and everyone disappears who doesn't have chat sounds disabled or is on Mac.
Could be triggered by C:\con\con, C:\nul\con, C:\nul\nul or just about any other combination of nul\con\aux, but C:\nul\con\con was my favorite, because Windows didn't just lock up on that one. It would blue screen, then every program you tried to use afterwards would just blue screen, background programs would just start disappearing, eventually leading to a total lock up. Ahhh, good ol' Win98...

Re:Similar feature in Windows

[Anonymous Coward]

I had the same thing happen.
It is quite common in teh cache folders of ISA server. Some websites are called http://aux.somedomain.com.
ISA server uses the site-name to save the cache-files....

AUX is a reserved filename for ancient CPM backwards compatibility reasons.
Same thing happens on COM, LPT, PRN, CON and probably some others I have forgotten.
And Windows only looks at the part of the filename before the period to determine if it is a reserved name.
That's why .COM as extension doesn't cause any issues.
(That is also a DOS/CPM leftover.)

Windows itself won't crash, but the file (after is has been written to disk) becomes inaccessible to all software. (And that software may crash because of that.)

The only way to get rid of such a file is to delete it with a very old DOS program that still uses the DOS 3.3 system calls.
Somehow that won't trigger the problem.

That is why I still keep a copy of good old LIST.COM around. It is a ASCII/HEX viewer but it can also do delete and rename files using the old semantics.

Abort, Retry, or Fail used to crash Mac TTS

[Anonymous Coward]

About 3 or 4 years ago it was possible to crash recipient's (iChat or radium, don't remember) IM app by sending Abort, Retry, or Fail? In an IM to someone that had text to speech enabled. Used to have fun with our manager. :)

It works

[spire3661]

Confirmed personally. OSX 10.8.2, 2011 mac mini. Entered the text into the search box in finder, crashed. It recovered fully in about 30 seconds though.

Let's look at the stack trace

[MrEricSir]

This is the stack trace mentioned in the article:
http://pastebin.com/UkhERvaA

Doesn't look like a c-string or printf issue to me at all.

Re:Let's look at the stack trace

[Anonymous Coward]

Very true, and even so deep in the stack trace hard to find exactly what it is. However after looking at that stack trace I would start poking around AppKit as I see a lot of similarities between this issue and issues with WebKit in general. So perhaps it is a flaw in AppKit or something passed up the chain to it: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Intro/IntroAppKit.html

I'm interested in what the answer is now- I wouldn't be surprised if it was caused by the excessive amount of Asserts that get left behind due to Apple rushing code production all the time and not refactoring with the best care. They still make good products though but some of the problems they create are quite the needle in the proverbial haystack.

Re:Let's look at the stack trace

[Hal_Porter]

They should comment out the call to DDCrash. As its name suggests that often causes problems

X-Sarcasm : This post is sarcasm.

Re:Let's look at the stack trace

[Anonymous Coward]

Parsing data revisited, anyone? Isnt it incredible a tokenizer/parse can take decades of work to settle down to a really useful syntax?

Doesn't crash Terminal

[PDG]

Tried it, capitals and all, no crash

Re:Doesn't crash Terminal

[Anonymous Coward]

No spell check in terminal, which is a part of this bug.

Re:Doesn't crash Terminal

[Anonymous Coward]

Terminal doesn't spell check its input.

Even crashes the crash reporter!

[Wormholio]

I tried this in Safari on Lion. Capital F required, but indeed just "File:/// " crashes it.
Then you get a pop-up asking if you want to report the problem to Apple? Sure.
But then that crashes with a pop-up reporting that crash reporter has crashed. Bonus!

Re:Even crashes the crash reporter!

[EmperorArthur]

Nice, it's an error large enough to prevent it from being auto reported, yet went quite a while before people noticed it.

Re:Even crashes the crash reporter!

[fnj]

Funnier than hell. In fact it's positively precious. I wonder where that shared library is actually trying to branch to when it happens.

Re:Even crashes the crash reporter!

[whoop]

To Apple's credit, they have received 0 reports from users of this crash. So, it can't be that important, right?

Re:Even crashes the crash reporter!

[Anonymous Coward]

I tried opening the crash log in Console.app, and that crashed too. Double Bonus!!

It's the old Windows 98 bug all over again.

[Dwedit]

You used to be able to BSOD a Windows 95 or 98 machine by trying to read C:\con\con, and this included any web pages that requested file://C:/con/con.

So, how can I type it for them?

[rduke15]

No one should ever need to type file:///
There are no bugs. You're doing it wrong

Yes, they are doing it wrong, by typing file:/// in lowercase, or not typing it at all. So the obvious question is: "how can I type it right for them?" If I include "File:///" in an email I send to a Mountain Lion user, will it crash his Mail.app? Or if someone quotes it in a reply here?

That could become a cool little meme.

Re:So, how can I type it for them?

[retchdog]

it's triggered by the spellchecker (roughly speaking, actually a bit more detailed), so it has to be in a text input field, and further the cursor has to be in the string (or something similar).

even replying to an email with quoting won't trigger the bug unless you edit the "File:///" string. a string which i just entered with chrome on an affected mac to no ill effect, btw.

it's an embarrassing bug, but not easily exploitable (though i'm sure someone will find some corner case).

Re:So, how can I type it for them?

[cheesybagel]

"not easily exploitable"? How about inserting it in a text input form and opening it in Safari?

Re:So, how can I type it for them?

[cheesybagel]

File:/// Or whatever.

Re:So, how can I type it for them?

[retchdog]

okay, fine. it won't do anything unless the victim clicks on the entry field. if they do, you've ... crashed their web browser. not the hack of the century, and the victim won't do it again.

sorry, i just don't see how this would be a problem. most websites don't want to crash their visitors' web browsers. i guess you can use it in a shock site, but hell, last measure (link mostly safe) was more annoying than this could be, and that didn't even exploit a bug.

Re:So, how can I type it for them?

[SuperKendall]

That gets you closer but the user still has to enter the textarea.

Re:So, how can I type it for them?

[tbird81]

When you crash, you're often inserting data to where it shouldn't be - sometimes this can trick the computer into running code.

Every time there is a crash, there's potential for an exploit.

Re:So, how can I type it for them?

[krinderlin]

Allegedly, it's even more complicated than that. It's in the Data Detector, which several apps will use on inactive text fields and other strings. You can actually send an iMessage from an iOS device to someone and it will crash the Messages app on OS X. Furthermore, you will be unable to re-open messages until you eliminate the message from your history database at the command line. (It's a sqlite database...I think.) Next, I managed to open a crash report from Mail in Console.app and said string crashed Console and then crashed the crash reporter. It was pretty wicked.

Re:So, how can I type it for them?

[retchdog]

yeah, except this is "crashing" due to a malcoded assert, as has been brought up many times on this forum.

that's basically the safest crash that's possible. i won't say it's unexploitable, but it's about as close as can be. you'd be better off looking for uncaught exceptions.

I actually typed it, and nothing happened

[mmarlett]

I searched in the Finder (iMac running 10.8.2) and got nothing strange. I tried Chrome, Firefox, Safari, Mail, a few text editors ... nothing. Sorry.

Re:I actually typed it, and nothing happened

[mmarlett]

Oh, wait, capitol F. That does cause a crash. Since when has a Mac been case sensitive? I guess that's what they get for listening to all those hackers complain about case insensitivity. ;)

Re:I actually typed it, and nothing happened

[EvanED]

From a comment above, the problem is that it's not case sensitive, except for an internal sanity check which is.

E.g. the dispatching code said "the user typed File:/// and I have a handler for file:///, so I'll call it", but then the handler had what was basically an case-insensitive comparison assert(url.startswith("file:///")).

So the problem isn't case sensitivity or insensitivity -- it's that it was being inconsistent about it.

Re:I actually typed it, and nothing happened

[Anonymous Coward]

Are all mac users this fucking dumb?

Re:I actually typed it, and nothing happened

[Anonymous Coward]

I know you're trying to be funny but with Mac OS X being a *NIX OS, pretty much everything is case sensitive, two files can have the same name and different capitalization in the same directory.

Re:I actually typed it, and nothing happened

[putaro]

Not true! HFS+ (the standard Mac file system) is case-preserving but case-insensitive (usually). Causes some real fun with SVN sometimes when people change capitalization on file names.

Re:I actually typed it, and nothing happened

[Anonymous Coward]

Your thoughts seem flawed. Mac has been "case sensitive" ever since it let you choose to type a capital letter or a lowercase one. They are represented by different values in memory, in files, etc. If you type out an essay and save it, and then you come back and open that document the next day, it will still be capitalized the same way it was when you typed it, because the capital letters are saved as capital letters and the lowercase letters are saved as lowercase letters. Many programs/features/etc. in the Mac world happen to ignore the difference, but the difference still exists. It's rather more likely that it's broken because they -didn't- check for upper/lowercase, and instead just pass it on unchecked to the URI parser which, by international standard, would like to see lowercase. Or, by writing a URI parser which didn't pre-convert upper to lowercase.

didn't some thing like @sony crash mac os 6?

[Joe_Dragon]

didn't some thing like @sony crash mac os 6?

Re:didn't some thing like @sony crash mac os 6?

[Anonymous Coward]

Yep, that was a similar problem to the AUX/CON issue that DOS/Windows still has. There was an invisible device representing the Sony floppy drive, and if you created a file with that name bad things would happen.

Freaking sh*t

[Anonymous Coward]

Just crashed my Safari - and now it won't reopen! It crashed my Internet! Help!!!

No crash on linux mint

[Anonymous Coward]

Cannot replicate in any app in linux.

Why is Apple shipping non-optimized code?

[Branka96]

If this is an assert as it appears to be, my question is, why is it in shipping code. Normally asserts are controlled by the NDEBUG symbol (or equivalent) which is undefined in optimized builds. In my opinion asserts should not be in shipping code. You should have something more solid in place.

Re:Why is Apple shipping non-optimized code?

[Anonymous Coward]

This is the only relevant comment

Re:Why is Apple shipping non-optimized code?

[Jeremi]

If this is an assert as it appears to be, my question is, why is it in shipping code. Normally asserts are controlled by the NDEBUG symbol (or equivalent) which is undefined in optimized builds. In my opinion asserts should not be in shipping code. You should have something more solid in place.

There is a school of thought that says that asserts should be left enabled in the shipping code, since otherwise the software you ship is going to be different than the software you tested against, with possible unfortunate results.

The original reason for disabling asserts for the release build was to maximize runtime performance, but that reason is less important for many programs these days, as there are more CPU cycles to spare.

Re:Why is Apple shipping non-optimized code?

[fnj]

And that, people, is why operating systems have become so grotesquely bloated and gigantic. An endless accumulation of "oh it's only a few more bytes".

Re:Why is Apple shipping non-optimized code?

[shutdown -p now]

asserts are there to catch bugs. Not invalid user input or other conditions that you can predict and gracefully handle, but actual programmer bugs - mistakes in the logic of the program.

If you ship your code with asserts disabled, you are, effectively, asserting that your code is bug-free. If you don't feel confident enough to make such a claim, then leaving them in there is a good idea - you lose a wee bit of perf, yes, but if things do go wrong, the user (and therefore you, when the user files a bug report with a crash dump) will find out much faster, and you will be able to pinpoint the problem more precisely. Furthermore, it prevents the program from running in a bad state and potentially opening up vectors for exploits.

Re:Why is Apple shipping non-optimized code?

[Anonymous Coward]

Disabling asserts is definitely for helping performance. So is turning on compiler optimizations that make debugging nearly impossible. If your asserts don't slow down your code, you don't have nearly enough of them. It's possible to use asserts to speed up non-debug builds these days too: when NDEBUG is defined, you can have a header replace assert with a gcc macro that branches to builtin_unreachable(), and then the optimizer knows about the assertion's constraints for optimization purposes.

Also, this 'school of thought' about shipping what you test is bogus: simply test the non-debug build. If it crashes, figure out how to reproduce the crash, and then reproduce it with a debug build. The debug build isn't for QA testing, it's for debugging a known problem.

Re:Why is Apple shipping non-optimized code?

[arth1]

If you ship your code with asserts disabled, you are, effectively, asserting that your code is bug-free. If you don't feel confident enough to make such a claim, then leaving them in there is a good idea - you lose a wee bit of perf, yes, but if things do go wrong, the user (and therefore you, when the user files a bug report with a crash dump) will find out much faster, and you will be able to pinpoint the problem more precisely. Furthermore, it prevents the program from running in a bad state and potentially opening up vectors for exploits.

It depends on the program. Sometimes you might want to let the program continue despite known errors, and leaving an assert would be a design error. Think car and airplane computers, data collection units, space probes, medical equipment...

Many of these would have redundant processes if not entire systems, so you could restart one while another was running, but more often than not, a failed assert in one of them would be a failed assert in all of them.

I'd think that the correct approach for an app that has a bona fide user feeding it input would be to give the user a choice - abort, or continue with a big red marker stating that the program is in an unstable state and that risk of crashes, corrupted data or security breaches will be high until the program is closed or restarted.
Perhaps the user really wants to at least try to save the pages he had typed in and not saved yet, or bookmark the web pages, submit a form, or otherwise save data or work.

Re:Why is Apple shipping non-optimized code?

[BasilBrush]

The balance between functionality and cost of space changed. If anyone is not using asserts for the reason of saving bytes, on anything other than a tiny embedded device, they are severely misguided.

Progress

[GrahamCox]

It's encouraging that such a minor obscure bug makes a supposedly newsworthy article. That's progress. Back in the day almost anything could crash a Mac (or any other PC), including just leaving it on for a sufficiently long period, so the fact that a crash of this type makes news today shows how much progress we've made.

WTF

[Anonymous Coward]

Ok, I didn't believe this, I thought it might be a hoax so I wanted to try this and typed it into a file in the TextEdit.app, and it crashed the TextEdit.app completely!!!!! I had a 10 page paper that I was writing in there opened and it hadn't failed yet. The paper is due tomorrow!! is there a way to sue apple for damages over this?!!?!!!!??

Re:WTF

[BasilBrush]

I realise this is a troll, but for anyone thinking it might be real:

He's just need to restart Textedit, and all the documents he had open will still be there, still opened, in exactly the state they were in seconds before the crash. Snow Leopard documents don't need saving, they are constantly persisted whilst editing. Even if you have't yet given them a filename.

Re:WTF

[squiggleslash]

I realise this is a troll

It was pretty obviously a joke, not a troll. You're not a Slashdot moderator are you? In my experience, they can't tell the difference either.

Spotlight

[Anonymous Coward]

Good way to restart Spotlight :)

Government response to terrorist commandQ attacks.

[geekmux]

Holy. Shit. We better add the Mac keyboard to the list of assault weapons quickly. They need to vote on banning those commandQ tactical strike weapons immediately.

Clearly Apple has been invaded by terrorists and we need 3 trillion dollars for the new iTSA branch.

Apple store employees will be trained by Navy SEALs and heavily armed. Those found executing any CLI in any Apple store will be deemed a terrorist threat and will be shot on sight.

Vote to rai...er, eliminate the debt ceiling in the name of terrorism.

Oh, and while we're at it, we're going to put all pot smokers on death row for their atrocious crimes against humanity to justify the War on Drugs.

(sad part is actual policy is passed with far more lunacy than this weak-ass example.)

Meh, it's deserved.

[Anonymous Coward]

Mehhh... if you're capitolizing the `f' in `file://' then you argueably deserve to have your .app crash... think of it as pavlovian negative feedback. We can all agree on this, you atleast should get some kind of punishment,,, agreed?
BTW I don't own any mac products at this time, so please don't call me one of those apple-user relate vile utterances (i.a., `mac fanboi'). tyvm

Are you sure it wasn't the Chinese?

[Anonymous Coward]

They're responsible for every computer fuck up now

Roosterteeth did this with your mind

[Anonymous Coward]

Orange Monkey Eagle
http://roosterteeth.com/archive/?id=4600&v=more

aah, I see

[Anonymous Coward]

it's a feature and I'm just holding it wrong... got it

Nope

[SuperKendall]

Just does nothing at all when clicked on, but that's not really a surprise since data detectors are not involved at that point. It's just rendering HTML so there's nothing to detect, the spec already says what it is and what it does.

It's "F" you f'ing morons

[Anonymous Coward]

Go F yourself if you can't be F'd to read and notice the F'ing capitalization, you motherF'ing F'ers.

Office handles this string perfectly

[raque]

Well, so much for the quality of Apple software compared to Microsoft. MSOffice 2011 handles this string perfectly. Every piece of Apple software goes down in flames. Word makes it into a link, Excel and Power Point treat it as text, I didn't pay for Outlook so I don't know about it handles this string.

Re:Office handles this string perfectly

[TheoCryst]

Try typing it into the search box in the toolbar in Word/Excel/PowerPoint. The document fields of the Office apps aren't "standard" OS controls (whereas the document body of TextEdit is), so they're not susceptible to the bug. But the search field, which appears to be a standard system search field, is.

Re:Office handles this string perfectly

[Anonymous Coward]

Outlook crashes.

Re:Office handles this string perfectly

[Anonymous Coward]

Outlook seemed to get hung up though.

It also crashes the error reporting function.

[raque]

If you're like me and send feedback to Apple when things go sideways, you can't on this. The Crash brings down the error reporting function "Problem Reporter". As soon as you click into the text field to describe the error it crashes too. Please note from my log:

2/2/13 8:43:18.001 PM Problem Reporter[517]: assertion on /SourceCache/DataDetectorsCore/DataDetectorsCore-269.1/Sources/PushDown/DDResultExtraction.c:1576 "CFStringHasPrefix(urlVal, CFSTR("file://"))" failed :wrong extraction: File:///
2/2/13 8:43:18.001 PM Problem Reporter[517]: wrong extraction: File:///
2/2/13 8:43:18.001 PM Problem Reporter[517]: An uncaught exception was raised
2/2/13 8:43:18.002 PM Problem Reporter[517]: condition "wrong extraction: File:///"
2/2/13 8:43:18.003 PM Problem Reporter[517]: (

I love the last line, is that open parenthesis supposed to be there all alone like that? This is a horrendous bug.

I noted that MSOffice seems to be immune. MS still uses Carbon instead of Coca as their framework. Is this a case of the old ways are still the best ways? Or is this an other case of Apple needs to improve their Quality Assurance.

Adam Engst of Tidbits has an article up on the Tidbits site on a Pages 4.3 bug that nearly prevented him from publishing his Take Control ebook on iTunes 11.

Version names vs numbers

[DulcetTone]

Why can't Apple stop using these hokey names for their software versions after release? There is no means of knowing what version it is, and it requires out-of-band knowledge of the most useless type. "About this Mac" quotes the grown-up version number. The names are 100% pure loss

A new feature!

[pjabardo]

This is apple we are talking about. Somehow this is a feature...

Redirection

[Anonymous Coward]

On Mac OS X 10.6.9, 'File:///' input to Safari directs to the volumes.

To my understanding Mac OS X 10.7 and later have attempted removal of the net BSD and other UNIX traits of Mac OS X.
That was the principal reason I have not upgraded nor bought a new Mac (Pro or Desktop or Mini).

Alas, I would say that it is the UNIX traits of Mac OS X that made it the winner in the 2000s. Now, Apple Computer has
morphed into Apple Inc. and have determined UNIX, which brought them back from the grave, NOT Steven P. Jobs, is
excommunicated.

This is now the reason for their fall in stock price and failure, as a company, as human beings.

When Apple Inc. stock price craters at $50, kiss good by their 'Star Ship' Headquarters.

No money to pay for it !

XD

Re:Redirection

[the_B0fh]

Do you live in the real world or in some made up fantasy world?

Lets assume that their stock price does magically fall to $50. They have $150 billion in the bank. How many fucking buildings do you think US$150 billion can build?

Snow Leopard FTW

[russotto]

Since I haven't upgraded thanks to Apple's removal of scroll arrows, I can still type "File:///" on my Mac all I want. However, I can't imagine why I would want to.

It would be funnier if merely RENDERING "File:///" would crash the Mac.

It is case sensitive

[PhunkySchtuff]

After trying this in every app I could think of, and failing to crash them, it turns out that this is case sensitive.

Some dude has done a more detailed analysis over on github but the long and short of it is that there is a specific check in the code for 'file://' and any other case will cause it to crash. All caps - crash. Capital F and the rest in lower-case - crash. All lower-case and a capital L - crash.

Similar bug in windows

[Anonymous Coward]

I found a similar bug in windows. When I type alt-F4 it crashes my programs.

Aquamacs

[smittyoneeach]

Aquamacs does not seem to understand what the slave process know as "OSX" is on about in this case.
Probably not important.

Re:Aquamacs

[EdgePenguin]

Aquamacs is more than capable of crashing itself without any dodgy library code.

Not Safari?

[Anonymous Coward]

Crashes Chrome when I type file:/// into the address bar. But does not crash Safari. Strange right?

Webkit?

Re:Not Safari?

[Anonymous Coward]

Um, and yes. I was typing with capital F. But not when I am posting of course. ;)

Automatic Hyperlinking

[ModernGeek]

It appears that this has something to do with URL validation for automatic hyperlinking in text fields. I am assuming that it does some sort of procedure that causes File:///[no carrier]

Re:Automatic Hyperlinking

[Anonymous Coward]

Probably since programs like Terminal aren't affected.

Re:Automatic Hyperlinking

[Gallomimia]

Agreed. I think that in the process of highlighting the hyperlink and finding the file it should be linking to, the background service eventually comes to a file descriptor that references no file and tries to dereference it. Some smart programmer is expecting the File:/// link to be completed all at once rather than typed in slowly. I would ask testers to try pasting in a full string that actually references an existing file and see if that causes the same results. Also a link that has a complete path for a file which does not exist.

The solution?

[Anonymous Coward]

Block java.

Terminal

[Anonymous Coward]

Doesn't crash Terminal though. Is there any significance to that?

Wonder what would happen if someone tried to make that their password.

Is this for real?

[the_B0fh]

Every single application I have open didn't crash.

Excel
Pages
Chrome
FireFox
Safari
Terminal
iTunes
Omnigraffle Pro
Activity Monitor
Keychain
Preview

Re:Is this for real?

[raque]

Did you capitalize the F in file? Are you running a version of Mountain Lion? The bug seems to be that the routine is not handling the capitalization properly.

Re:Is this for real?

[__aaltlg1547]

I disagree. I think the problem is trying to "handle" user input that isn't intended to be executed at all.

Re:Is this for real?

[raque]

The MacOS checks each string as you type it, that's how it spell checks and things like that. If you look at the language and Text panel in the System Preferences you will see check boxes for spell checking and replacing text with certain symbols: like a copy write symbol if you type (c). This is how if you get a date in your email the OS can offer to make an appointment in iCal for you, passing info between applications is an OS function. That process has a flaw which causes a crash when it encounters that particular string. There are some more detailed explanations above.

Re:Is this for real?

[the_B0fh]

Yes and yes.

Re:Is this for real?

[__aaltlg1547]

The MacOS checks each string as you type it, that's how it spell checks and things like that. If you look at the language and Text panel in the System Preferences you will see check boxes for spell checking and replacing text with certain symbols: like a copy write symbol if you type (c). This is how if you get a date in your email the OS can offer to make an appointment in iCal for you, passing info between applications is an OS function. That process has a flaw which causes a crash when it encounters that particular string. There are some more detailed explanations above.

Yes, I understand what the feature does and what people use it for. But understanding what it is for does not result in my thinking that it is a good thing to have a subsystem searching user input and other data sources for anything that looks like a file reference.

Maybe you wonder why that's an issue. It's because referencing a file is a half step from opening it. Opening it is tantamount to editing it or executing it if it's executable. By attempting to generate a shortcut to open the file, the system is exposing the user and every program to potentially opening, editing and executing files accidentally when it would not otherwise be the case, and counter to prevailing expectations of what user inputs are supposed to do in the program the user is using.

Re:Is this for real?

[petervandervos]

Are you sure? I tried Pages, Chrome, Safari, Preview and iTunes and they ALL crashed. Try opening a search box or load a file. Type the string on the Comment: page of slashdot => crash. If the spellchecker kicks in, it crashes the program.

Re:Is this for real?

[raque]

In that case we are in complete agreement. Just because you can do something doesn't mean you should.

I get why people get so enamored of what computers can be made to do. As someone with writing based learning disabilities Mac and spell check changed my world. I went from not being able to finish High School to Honors in College. WriteNow and MacWrite Pro with that little 9 inch black and white screen were magic in the most pure Harry Potter way. I took my minor in computer science so I could understand this tool that freed me.

I'm amazed by what people don't care about and don't want to know. Just make twitter work .. Wow I'm the mayor of something on Foursquare ... What are people saying on Facebook? Send me your contact info and we'll set up a date. It goes on and on. Just because the first one was a good idea doesn't make the second, or third, or fourth one a good idea too. Matt Hanan found out that Apple's Opaque nature makes them difficult to trust. I've spoken to friends about how all of this interconnected, I'll do it for you-ness may not be a good idea. That cloud services have to be monitored and secured. What I get back is a suspicious look and being asked why I want to take their twitter from them. How can they live without it, it's magic. If you point out that magic has side effects and things you don't see I get more suspicious looks. It's rather bizarre.

       

Re:Is this for real?

[Anonymous Coward]

Try TextEdit, or an application that uses the Operating Systems native spellcheck in a text field. Pages, though created by Apple, might be using something different for text rendering/layout.

it's an old joke

[PopeRatzo]

"Doctor, it hurts when I do this... Can you help me?"

"Sure, don't to that."

I'm going to give some free advice to users of Apple's OSX Mountain Lion: Don't do that.

Re:it's an old joke

[Anonymous Coward]

A guy walks up to the Genius Bar and says, "Hey when I type in 'File:///' my Mac crashes".

The Genius replies, "Ah, you need to type it with your Left hand".

you obviously didn't read it

[Chirs]

It's a commented assembly listing with a proposed hacky fix in assembly.

It works for File filE fILe etc.

[Anonymous Coward]

It is a uppercare/lowercase problem. They test for file:// exception by making a lower case comparison, which means File:/// FILE:/// fILE:// etc. all slip through, which causes a different type of object to get returns to programs which don't except it.

assert() expression in release? Deeper still?

[Anonymous Coward]

I wonder if it's an even more insidious problem, such as a compiler bug where the assert() isn't checked, but the expression being asserted is evaluated anyways. *That* would be insidious, since the (good) practice of making the assert() calls not go off would work to *actively hide the problem*!

What you call a bug...

[Anonymous Coward]

I call a feature. Another option to Force Quit is great!

Hater Fail

[SuperKendall]

You did realize that a link does NOTHING because it's a bug in auto-detect code, right? I mean a link you post doesn't need to be detected, because it's a link... so clicking on your link on a Mac does NOTHING WHATSOEVER.

What a doofus.

Now, to use some JavaScript or HTTP Redirects to auto-load that URL, and have some REAL fun.

Which would have the same effect... I'm not sure why you get your jollies out of posting links that are inoperable, you may as well be posting text marked-up to have underlines.

My Fix

[SuperKendall]

My fix is much simpler, to never type in a string I have never typed before for any reason anyway.

I mean, honestly - who capitalizes a URL scheme anyway? A C# developer? Madness.

This doesn't happen in FreeBSD

[Anonymous Coward]

So what company was it that got the BEST developers from FreeBSD? Oh, never mind that company won't be around much longer anyways.

oh ya.

[AndyKron]

It just works...

I've been closing my apps that way for years.

[joelville]

I thought everyone knew File:/// is the new Command-Q

Auto-quoting?

[Misagon]

I wonder if automatic quoting of a message on an online message board could cause a crash of the web browser ...
Many message boards, although not Slashdot, has quoting of the previous message enabled by default when you click the [Reply] button. That would copy the previous post into a text field, which would trigger the bug, apparently.

Then all a MacOS/Mountain Lion user would have to do to crash his web browser on those message boards would be to hit the Reply button to the wrong post.

I expect File:/// trolling to explode on message boards in the next few days ...

Agreed, 110% (I use this method)... apk

[Anonymous Coward]

" Crashing is not dealing with the error." - by Darinbob (1142669) on Saturday February 02, @09:54PM (#42775199)

See my subject-line above, & this -> http://apple.slashdot.org/comments.pl?sid=3429511&cid=42776753

Mainly since I provide an example in code per your statement...

* :)

(Total agreement here with your sentiments, & that's how I deal with that @ times (on the override of std. err-handling by compiler structured error handling)).

APK

P.S.=> It works, & apps don't "fall on their face" plus, letting the user 'recover', as well as the app itself, gracefully MINUS "crashing", too (At times, I even pipe std. errs from compiler structured error handling to a log, & give the user a 'friendlier message' to contact sysadmins or developers with)

For the user: By making sure controls they used re-enable as well (since I disable them, & especially IF/WHEN they're spawning multiple threads to avoid race conditions & such) & issuing them a message they can understand better, if not warn them to contact devs/admins in that instance also (who get the actual errlog with the more 'complex' message from structured error handling)...

... apk

Re:Agreed, 110% (I use this method)... apk

[Anonymous Coward]

Hey apk,
  Isn't it great to participate in the conversation without going on and on (and I mean on) about host files? I like this apk. Set up an account and stay a while!

Patent

[Anonymous Coward]

Apple, patent this!!! Patent this bug quickly!!!

It's worse than that

[ebcdic]

It turns out that some programs (e.g. Unison, a usenet reader) will crash if they try to display a document containing the string. Quite possibly more will turn up - they'll be programs that try to recognise URLs and display them as a link.

Future Tech

[Anonymous Coward]

If you are into exponential tech and futuristic tech check out my blog. Heres one on synthetic meat. http://mikecole858.blogspot.com/2013/02/fake-meatits-whats-for-dinner.html?m=1

This is appalling

[richardcavell]

Everyone's making fun of this, but this really is appalling. Apple has had nothing but trouble since Steve Jobs died. Just as people predicted. It shows that modern OS's are so bloated that it is impossible to remove all bugs. OS X and Windows 8 probably contain other similar bugs, but we just haven't found them. I would like to believe that bug-free code is possible. Perhaps Apple need to change their programming paradigms. If you want true security you need to greatly minimize your operating system and compartmentalise its tasks, so that it can be exhaustively bug-checked. Adding "features" to an operating system simply creates new security holes. We laugh at the Space Shuttle for running on 386's, and there's a bank here that still runs its terminals on OS/2, but there are applications for which code reliability is absolutely paramount. Think of space probes, nuclear weapons, pacemakers... Richard

Re:This is appalling

[Anonymous Coward]

Everyone's making fun of this, but this really is appalling. Apple has had nothing but trouble since Steve Jobs died. Just as people predicted.

What's appalling is that you trotted out this dumbass, tired post-Jobs decline meme so beloved of lazy thinkers, and appear to expect that it should earn you some kind of respect for wise commentary. Apple did not write perfect, bug-free software before Steve Jobs died. They will never write such software in the future. As you yourself appear to be aware, that is impossible.

What's worse for you is that this particular bug is, in the grand scheme of things, very minor. It sounds like someone added some last-line-of-defense input validation assertions to existing code paths (probably after a security review), but made a mistake which causes false positives. Oops, but relatively little harm done since it's a controlled crash, not an attack vector, and the bug is triggered so rarely that it took about a half a year of 10.8.x being installed on millions (probably tens of millions) of computers for anybody to notice.

It shows that modern OS's are so bloated that it is impossible to remove all bugs. OS X and Windows 8 probably contain other similar bugs, but we just haven't found them. I would like to believe that bug-free code is possible. Perhaps Apple need to change their programming paradigms.

I've got bad news for your rosy view of the past and your desire for a paradigm shift: it has never been possible to remove all bugs in personal computing, no matter how simple the code. I learned to program on the Atari 800XL, which had a 16KB ROM (some of which was for the built-in BASIC interpreter, not the OS). That's smaller than the 'cat' binary on this Linux system, yet Atari had bugs. They never fixed all of them despite the OS changing very little over its whole lifespan.

If you want true security you need to greatly minimize your operating system and compartmentalise its tasks, so that it can be exhaustively bug-checked. Adding "features" to an operating system simply creates new security holes.

Guess what, Apple's been working on compartmentalizing and simplifying security analysis (via sandboxing) the last few years! The first preliminary steps shipped in 10.6 "Snow Leopard", two major releases behind the one TFA's talking about.

We laugh at the Space Shuttle for running on 386's, and there's a bank here that still runs its terminals on OS/2, but there are applications for which code reliability is absolutely paramount. Think of space probes, nuclear weapons, pacemakers...

The Space Shuttle flight computers did not use 386 processors. The 386 didn't even ship until after the Shuttle had begun flying. It used avionics computers derived from IBM's System/360, a much older design.

http://en.wikipedia.org/wiki/IBM_AP-101

there are applications for which code reliability is absolutely paramount. Think of space probes, nuclear weapons, pacemakers

Yes, there are, and guess what? It costs. IIRC, Shuttle flight software cost ~100x more per line of code than typical software. Functionality was limited to the bare essentials (ascent, orbit/maneuver, descent, and landing), and the system didn't have to even have to be designed to keep hostile hackers out.

As of OS X Mountain Lion, Apple's charging $20 for a major upgrade, and targeting one major upgrade per year. I know that price is not the same thing as cost, so it's hard to say exactly how much Apple would charge if they upgraded their quality standards to Shuttle flight software levels, but would you be willing to pay on the order of $2000/yr for a desktop OS? Would you be willing to wait maybe 5 years between major releases? Would you live with a tiny feature set? With the inevitable dips below Shuttle flight software quality standards when running 3rd party application software not under Apple'

Username

[Anonymous Coward]

Is it possible to change your login name to: File:/// ? If so what happens?

BS

[Anonymous Coward]

Yeah, right. As if I'm going to crash my Mac by simply typing File://

How many people does this really effect?

[gravis777]

It's an odd bug, but how many people are really going to be using this command on a Mac? Let's rephrase that: how many people actually know of this command, Windows or Mac users? I have probably used this command maybe a half dozen times in probably 10 years, and that is because Explorer or something has hard locked on me, and killing and restarting the process doesn't work, and I need to save or copy or move something before I reboot.

Now I will grant that I know many more geeks and nerds on Macs now than even 5 years ago, so I am not going to make the joke that "no Mac user would use this". I am just wondering how many people this really effects, and even those users who know about the command, how many would know that it was broken if not for this article.

No crash on my system

[geo3rge]

I tested this on my Mac running Mountain Lion. I tested with Safari, BBEdit, and Mathematica. NO CRASH. something else is going on here.

Re:No crash on my system

[konohitowa]

1. Make sure it's not all lowercase in 'file'.
2. In Safari, type a space after the 3rd slash to activate the checking.

I don't get it

[pyrothebouncer]

Why would you be typing "file" anything in Mac OSX? Trying to relive your old DOS days?

Bunch of weirdos....

Autocorrect

[Kenshin]

Apparently this is a fault with autocorrect, which is enabled-system wide. If you disable it the bug doesn't work anymore.

Cool!

[desertfool]

It not only crashed Safari, but also crashed the bug report when I typed what I did to cause the crash!

This is fun!

Yes it does... :-(

[Douglas Goodall]

I find it hard to believe such an error exists, but I tested it on my MacBook Pro by typing it into Safari "File->OpenLocation" and sure enough it a bended Safari just like that. I said, "Dad, it hurts when I do this...", he said, "Don't do that". Given that this is now a known and discussed , it is very surprising that it has not been fixed right away by a software update. It does not take admin privileges to try to open a file by that name. Now all it seems to do is crash a single App, like Safari, but what if this was fed to a system process such that it cripples the OS if it crashes?

Obligatory xkcd

[Anonymous Coward]

http://xkcd.com/1163/

(Referring to the image title tag.)

Bogus

[Anonymous Coward]

Tried this on my ML Mac and it only crashes TextEdit, not "almost every application".

All software has bugs?

[Anonymous Coward]

I hate this false blanket statement that is commonly used to defend shitty software. All software does NOT have bugs! If all software had bugs, no software would act as designed and no software would function correctly; Computer use would be virtually inpossible. A more correct statement would be "As complexity in software increases, so does the propability of bugs."

Doctor, doctor..

[Ginger Unicorn]

Doctor, it hurts when I go like this.

Don't go like that then.

con/con strikes again!!!

[Anonymous Coward]

There have always been problems like this and I always think they're hilarious. In old versions of Windows you could click Start -> Run -> and type con/con. Hit enter and the system would blue screen

Hey Sardaukar86 (you troll)

[Anonymous Coward]

Wouldn't it be great IF you knew how to do things like this -> http://apple.slashdot.org/comments.pl?sid=3429511&cid=42776753

So you too could actually contribute AND be on topic instead of being a troll like yourself that actually has a "registered 'luser'" account but is trolling me by ac posts all thru your posting history for weeks now -> http://slashdot.org/~Sardaukar86 ?

Re:Mods have no sense of humor

[Anonymous Coward]

Butthurt fanboy detected.