Maybe I should, but 10.8's Terminal.app seemed to have everything I need (well, except for the crash reporter ruining my work every time I forget and type ~)
You know, it's funny. I said the exact same thing you did, then a friend convinced me to try iTerm2 about a year ago. I still couldn't put my finger on what's better about it, exactly, but I've never considered going back after the first day. It just feels right.
It's probably easier to try than it is to find out why to try it...
Doesn't crash my Terminal.app. I use a swedish keyboard. Perhaps you could create a new clean account on your computer and try it there? You can always delete the account afterwards.
Yup, and that's why I suggests you create a new fresh user and try it there. If the bug doesn't show there it's something in your personal settings somewhere, if not it's in the system settings.
Can you give us the steps to reproduce? I googled around but couldn't find the bug. I also tried a few different languages and I can't get Terminal.app to crash.
I'm also running the latest version of Chrome on Mountain Lion on a current Macbook Air, and I can't reproduce this. Entering file:/// just shows me "Index of /" as expected.
I try to avoid upgrading OSX. When a new version comes out, I wait for a hardware refresh and just get a new Mac (Apple has a nasty habit of disregarding backwards compatibility, and it's really nice to be able to do stuff like run older powerpc programs)
EDIT: the [deleted] comment was 'I miss snow leopard'
> Apple has a nasty habit of disregarding backwards compatibility
On the hardware front, every single major update runs better than the one before here (Mid '09 MBP 13", originally under Leopard). Only issues were the battery on Lion an Mountain Lion on both .0 and .1 minors, which was a bug that affected everyone.
Backwards compatibility refers to newer software/hardware not supporting older software/hardware. For example, Apple axed the rosetta powerpc support (which allowed you to run older software after apple switched to intel CPUs) in Leopard. I still keep a PowerBook G4 just for MacDraw.
Rosetta is optional but supported on Snow Leopard, and gets downloaded automatically on demand. Seven years of transition (assuming SL stopped to be supported when ML was released) to Intel was more than enough for active software to be ported.
You just can't carry legacy code indefinitely, you have to stay focused or you'll be all over the place and suffer death by a thousand cuts.
I intuitively agree as a programmer, but in practise, the focused 10.7/10.8 line has been pretty buggy compared to the legacy-happy 10.6; and the legacy-happy Windows 7 was a smash hit compared to the focused Windows RT. Of course, it might be even worse with Rosetta added to the mix...
I've also given away my Mid-09 MBP because 10.7 Safari was terrible without an SSD ("blank page" bug) :(
Even that strategy isn't enough. I bought a Retina MBP with Lion pre-installed, which was the only configuration they sold, so you'd think it would have been pretty well tested. It turned out that the Lion video drivers couldn't handle the retina display. I had full machine crashes three times a day. Others online had the same problem, and some who were beta testing Mountain Lion said the new video drivers had cured their crashes. As soon as ML was released, I took the free upgrade, and the crashing stopped.
I then upgraded my kids' Snow Leopard Mac to Mountain Lion so I'd only have one Mac OS to admin (along with my Windows, Linux, iOS, and Android machines...sigh). The Mountain Lion upgrade caused all sorts of headaches on the kids' machine.
Moral: The new Mac OS version you buy might not be compatible with your Mac, even if it's the OS that came with it.
When you have a business, its far easier to just purchase a new machine and expense it than it is to upgrade existing machines. Time is far more value than money, and I'd much rather spend 3K for a new machine than waste a day or a week struggling with an upgrade issue and dealing with AppleCare.
PS: it's eligible for section 179 accelerated depreciation and sales-tax free in NY thanks to ST 121.3
Please note my reply was meant to be taken as a joke. I expect most people don't need to refresh their Apple gear on a yearly basis, but that is a bit of the stereotype of an enthusiastic Apple fan, and your post can be taken humorously to fit that image. Of course with Apple the answer is always more hardware. :-)
Hilariously, this bug seems to also crash the Mac error reporter, maybe because it has the evil string in it. I did manage to copy and paste a crash dump before the crash reporter crashed: http://pastebin.com/UkhERvaA
The underlying reported error is
* Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'condition "wrong extraction: File:///"'
Interesting that it's an asynchronous crash. What part of MacOS is paying such close attention to typed URLs?
From the openradar bug, it is obvious that the bug is inside the "Data Detectors" thing. Looks like it triggers on anything starting with file:// (+/) case-insensitive, but then something later in the data extraction makes the incorrect assumption that the string should start with file:// (+/) lowercase, and throws an assert.
It's really quite bad that a bug inside the data detectors can bring down a whole app.
The data detectors, at least in my TextEdit were turned off (never touched it before) so typing the aforementioned string doesn't cause any issues.
However in my stupidity of attempting to tell you guys that I could type the aforementioned string, I caused Safari to hang. No crash, but it was complete and utterly useless.
checkDataDetectors will extract 'File://a/' - or any other 'complete' file URL - which at a minimum is a schema (file://) and a path '/' - as a valid data URL and then pass it to DDResultCopyExtractURL, which does some additional sanity checking.
There it validates it by asserting that the URL begins with 'file://', which it doesn't. It then converts to an NSInternalInconsistencyException which is what crashes the application, since it isn't caught.
The timing differences that people are seeing is because the NSSpellCheckerCheckString process checks the spelling only after your key entry has been idle for a short period.
checkDataDetectors will also run if you simply open a file or application with this text inside it in a text control. When declaring your text control class you can disable the automated spell checking and data extraction (which will run even if you have spell checking disabled).
There really is no need for this thread to be filling up with 'it works on x, doesn't work on y', since we know what causes this (any NSTextField on Mountain Lion).
If you want to have a look at it and can't read the crash report, attach to TextEdit with gdb
$ gdb /Applications/TextEdit.app/Contents/MacOS/TextEdit
(gdb) r
<switch to textmate and type 'file://a/aaaaa' into a new doc'>
(gdb) <crash report>
(gdb) disass DDResultCopyExtractedURL
<dump of function>
Unhandled exceptions can't be exploited in general, because they safely unwind the stack and terminate the application. This crash is just an unhandled exception. By contrast, a segfault (at an address other than NULL) would be more interesting from a security perspective.
If you're stuck because you typed this and now your app is automatically crashing itself all the time, go to System Preferences, under Language & Text, Text, uncheck "Correct spelling automatically" _and_ "Use symbol and text substitution". Both need to be unchecked.
You can use TextExpander to work around it temporarily. Just map {The bad string that starts with 'F' that I cannot type here} to file:/// and it seems to add some protection.
so, uh anyone else sense a zero day exploit? <a href="File:///<insert code here>">click me</a>... not saying that will work, but usually if you can hard crash something you just found some corruption in memory maybe bad use of memcpy, sprintf instead of snprintf... something along those lines...
Tried it out by sending an email to myself (from webmail) and opening the mail in Mail.app. Mail.app doesn't crash, but if you hit reply to the message and put the cursor on the "File:///" part, it does crash.
- Skype (type and right mouse click)
- Sparrow (type and wait)
- Chrome (address bar)
- Safari (address bar)
- Tweetbot
- Twitter.app
- Mac App Store (search bar)
- Base (any textbox)
- terminal (in the preferences screen)
Not crashing:
- SublimeText
Pretty much each and every text box on the entire system.
The fun thing about having it in messages.app, is it is actually a bug on the RECEIVING end of messages.app. And I can't seem to delete the message before the app crashes again.
People act completely stupid when it comes to their OS. HOLY SHIT THERE'S A STANDARD TEXT FIELD CLASS?!?!?! APPLE IS DOOMZ0R3D!! Be a champ and submit these kind of things to your local devs and (as the super "hacker" posters say) carry on...
Oh, please. What is a standard text field class doing with the text inputted into it that would cause an entire app to crash? It's a ridiculous scenario.
Would you have the standard text field run in a separate process sandbox? Or not have standard widgets shared between apps? Or just try real hard to write code without bugs?
Listing every single app under the sun when it's completely obvious a common and widely used component (doesn't matter what's its name so really no need to know Cocoa and that it's probably NSTextView) is used is acknowledging it as voodoo.
The likelihood of python/ruby/PHP/etc. programmer being able to interpret a native code stack trace is... what? Probably quite low. They might not even know what the function call names imply. And yet they'd fit perfectly in to this site's readership.
System-wide means it's Spell-Checker's fault.
I have a MBA '11 11 with 10.8.2 and Safari won't crash.
I have disabled Spell-Checker from the start (annoying it).
205 comments
[ 2.5 ms ] story [ 241 ms ] threadIt also has great tmux support built into the client.
It's probably easier to try than it is to find out why to try it...
https://github.com/gnachman/iTerm2
How did this bug survive the testing process?
Wait. I think I just answered my own question.
I can't believe there's no-one at Apple using i18n keyboard layouts and Terminal.app.
It's not like typing "~" is an uncommon event on the command line....
Meanwhile, VLC fixed the same bug (typing ~ in the VLC.app UI textfields) in about 30 minutes.
Edit: Here's the same bug in VLC: https://trac.videolan.org/vlc/ticket/7268
(Chrome version 24.0.1312.57 really doesn't crash for me on Mac OS X Mountain Lion. Safari and TextEdit do, though.)
Tried it in Safari and Firefox too, no issues.
OK, it also crashes Safari when capitalized.
Just tried in Mobile Safari and Noted in iOS 6.1, no problems there.
EDIT: the [deleted] comment was 'I miss snow leopard'
On the hardware front, every single major update runs better than the one before here (Mid '09 MBP 13", originally under Leopard). Only issues were the battery on Lion an Mountain Lion on both .0 and .1 minors, which was a bug that affected everyone.
You just can't carry legacy code indefinitely, you have to stay focused or you'll be all over the place and suffer death by a thousand cuts.
I've also given away my Mid-09 MBP because 10.7 Safari was terrible without an SSD ("blank page" bug) :(
Which they backed off from. You can probably thank Flashback for that.
I then upgraded my kids' Snow Leopard Mac to Mountain Lion so I'd only have one Mac OS to admin (along with my Windows, Linux, iOS, and Android machines...sigh). The Mountain Lion upgrade caused all sorts of headaches on the kids' machine.
Moral: The new Mac OS version you buy might not be compatible with your Mac, even if it's the OS that came with it.
Apple must love you.
PS: it's eligible for section 179 accelerated depreciation and sales-tax free in NY thanks to ST 121.3
The underlying reported error is * Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'condition "wrong extraction: File:///"'
Interesting that it's an asynchronous crash. What part of MacOS is paying such close attention to typed URLs?
It's really quite bad that a bug inside the data detectors can bring down a whole app.
Edit: some interesting links:
http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”")
https://developer.apple.com/library/mac/#documentation/Found...
However in my stupidity of attempting to tell you guys that I could type the aforementioned string, I caused Safari to hang. No crash, but it was complete and utterly useless.
There it validates it by asserting that the URL begins with 'file://', which it doesn't. It then converts to an NSInternalInconsistencyException which is what crashes the application, since it isn't caught.
The timing differences that people are seeing is because the NSSpellCheckerCheckString process checks the spelling only after your key entry has been idle for a short period.
checkDataDetectors will also run if you simply open a file or application with this text inside it in a text control. When declaring your text control class you can disable the automated spell checking and data extraction (which will run even if you have spell checking disabled).
There really is no need for this thread to be filling up with 'it works on x, doesn't work on y', since we know what causes this (any NSTextField on Mountain Lion).
If you want to have a look at it and can't read the crash report, attach to TextEdit with gdb
Also, this means the bug can't be exploitedBug report says 10.8.2. I don't see this problem on 10.7.5 as the addendum mentions no problem in Lion.
In one instance the Sparrow crash caused the entire mail library to be corrupt and I have to download all my mails again.
I'm so happy I have nice friends.
sqlite3 ~/Library/Messages/chat.db "delete from message where text like "%File:%"
People act completely stupid when it comes to their OS. HOLY SHIT THERE'S A STANDARD TEXT FIELD CLASS?!?!?! APPLE IS DOOMZ0R3D!! Be a champ and submit these kind of things to your local devs and (as the super "hacker" posters say) carry on...
I only see someone who said that it was safe to type it in a software, but I can be wrong.
Listing every single app under the sun when it's completely obvious a common and widely used component (doesn't matter what's its name so really no need to know Cocoa and that it's probably NSTextView) is used is acknowledging it as voodoo.
Right now, Sublime seems to be the only one. Anyone care to try TextMate?
(This is true of basically every OSX app there is)
Spotlight.
Find field in chrome.