Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Picking Apart the Crashing iOS String

manishearth.github.io

Post reply on HN
Print view View original

161–170 of 182 posts

Re: Picking Apart the Crashing iOS String

#161

Post by Manishearth »

ktta wrote: post #122
kens wrote: post #38

Not directly related to the crash, but I have a question about Telugu and similar scripts: How do their speakers think about the structure of the script? Do they consider each vowel and consonant a separate "thing" that just happens to get written as a complex grapheme, or is the grapheme the unit you think about and it just happens to be made up of smaller parts? I.e https://en.wikipedia.org/wiki/Telugu_script#Conso…

Telugu is my native language. Here's how I learnt it. There's two types of letters. One type is used as an addendum to the other type. The first type are called vowels and the second consonants (I'd say that's mischaracterization but whatever). In this[1] picture, the top half of the alphabets are the type which are the addendum part, and the bottom part are the 'primary' ones. So how it goes is that one of the botto…

> Congratulations, you can now pronounce (almost all of) Telugu (and almost any Devanagari script using this same play book). It is because these scripts are deterministic, and there is a single pronunciation unlike English and many other languages.

weeeellllll, not exactly. For example, spoken Marathi differs considerably from written Marathi, with vowels turning into other vowels, etc. My favorite example is the word लहान which is spelled "lahaan" but is often pronounced pronounced "lhaan" OR "laahaan".

Almost all Indic language experience schwa deletion -- you will say the word "kanpur" with no vowel between the n and p even though it is spelled "kanapur". Anusvars have a range of pronunciations that depend on the word being used -- they can nasalize a vowel, or add a nasal consonant like n or m.

However, these scripts are definitely way more phonetically consistent than English. These differences are minor.

Re: Picking Apart the Crashing iOS String

#162

Post by Manishearth »

calvinbhai wrote: post #115

@Manishearth Thats a great explanation (though quite a bit of it was too much for me to understand). The only correlation I can think of, is that the Kannada script keyboard and full support for the script rendering in the UI didn't exist in iOS until iOS 11.0. So it is crashing for Indic scripts that were supported pre iOS 11. Probably Apple tweaked something in iOS 11 for the languages already supported and broke s…

Huh, that's an interesting theory.

Re: Picking Apart the Crashing iOS String

#163

Post by cesarb »

beojan wrote: post #151
thezoq2 wrote: post #146

Earlier quoted context omitted.

An out of bounds access doesn't have to lead to a crash. For most types in the standard library, the [] operator crashes but the "get" function returns Result which you can deal with.

So it's really no better than C++, where containers have a `.at` function that does bounds-checking and throws an exception if out of bounds.

The difference is that on Rust the [] operator does bounds checking: it'll reliably panic before accessing memory if the index is out of bounds. While on C++, the [] operator will happily let the program read or write outside the array bounds.

Depending on compile-time options, a Rust panic can either cause an immediate crash, or do something similar to throwing a C++ exception, complete with stack unwinding.

Re: Picking Apart the Crashing iOS String

#164

Post by charrondev »

userbinator wrote: post #123
enzanki_ars wrote: post #65

Earlier quoted context omitted.

Given that Apple does not design their OS to work on anything but their hardware, the pain I would incur trying to set up either option is just not worth it. Unless someone has published a stable and updated pre-built VM for macOS, it just seems like nothing but trouble.

Not so long ago I was pleasantly surprised by how easy it was to setup a Hackintosh VM in VirtualBox --- all I did was create a VM with the default settings, add the all-important SMCDeviceKey, insert a completely stock El Capitan ISO, and it booted up and installed on the first try. All on hardware that was as non-Apple as it gets (a ThinkPad.) The only thing that I found somewhat confusing and perhaps a bit un-Appl…

Like because there isn’t a single current official device with a user replaceable hard drive.

Re: Picking Apart the Crashing iOS String

#165

Post by Manishearth »

cesarb wrote: post #163
beojan wrote: post #151

Earlier quoted context omitted.

So it's really no better than C++, where containers have a `.at` function that does bounds-checking and throws an exception if out of bounds.

The difference is that on Rust the [] operator does bounds checking: it'll reliably panic before accessing memory if the index is out of bounds. While on C++, the [] operator will happily let the program read or write outside the array bounds. Depending on compile-time options, a Rust panic can either cause an immediate crash, or do something similar to throwing a C++ exception, complete with stack unwinding.

Yeah, and because it's reliable, you don't need to worry about security issues -- the worst this can do is abort the application.

Whereas for this bug it's quite possible that it may be exploitable. Especially given that the crash backtrace doesn't always appear in the same place -- something is corrupting memory that gets discovered later. (This explains why I can sometimes get the string to render for a split second before crashing)

Re: Picking Apart the Crashing iOS String

#166

Post by crumbshot »

vxNsr wrote: post #154
crumbshot wrote: post #99

Earlier quoted context omitted.

Someone posted a crash report: https://gist.github.com/steipete/a759b56dc1b5d94ba5b3c03ddd0... Looks like a heap corruption, leading to a failure when allocating memory later on: Application Specific Information: abort() called *** error for object 0x604000673e00: Invalid pointer dequeued from free list Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff73a30e3e __pthread_kill…

This char string will crash safari on my up to date Mac.

Could you run Safari under lldb, setting environment variable DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib?

Should look something like this:

    $ lldb /Applications/Safari.app/Contents/MacOS/Safari
    (lldb) env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
    (lldb) process launch
Assuming this is a heap buffer overflow, this should cause it to crash at the point of memory corruption, as it hits an adjacent guard page.

Re: Picking Apart the Crashing iOS String

#167

Post by floatboth »

lloeki wrote: post #95
Someone1234 wrote: post #91

Earlier quoted context omitted.

Or just move CoreText into its own process, and restart it when it crashes. The big issue is that when CoreText crashes right now the kernel panics and the device restarts. If CoreText itself could crash safely, get restarted, and the OS continue running then these bugs would go from "significant" to "annoying." Even if CoreText crashing caused individual apps to also crash, that would be a big improvement the curren…

From what I gathered so far this doesn't hit the kernel but the process. It seems to turn out that on iOS one of such processes happens to be Springboard, hence the UI (but not the kernel) gets a kick and restarts. Maybe I missed something though.

Yeah, Springboard is responsible for not just the home screen but also notifications. So if that sequence of characters arrives in a notification, Springboard will restart… and try to show the notification again… and restart…

Re: Picking Apart the Crashing iOS String

#168

Post by stcredzero »

annabellish wrote: post #144
stcredzero wrote: post #77

Earlier quoted context omitted.

You realize that there's no such thing as "don't ever crash" fix, right? You answered universally for all contexts, ever, everywhere. That's a usually quite a foolish thing to do. In ObjectStudio Smalltalk, there was actually a place where you could define an empty lambda as the "top-level" exception handler. Once you did that, all Smalltalk exceptions did nothing. There you go: a "don't ever crash" fix, in a languag…

Yikes. Instead of having heap corruption which immediately causes a hard failure, you want heap corruption which is silently ignored and (?????) happens on a device in which people access banking and all their personal identity stuff?

No. But the heap corruption shouldn't make certain facilities go away, or hang around looking broken. For example, Springboard could be separated into separate processes (display and monitor) and built on some kind of event queue. Then, if an event containing some kind of poison pill brought down the display, the monitor could note the crash and after a few retries, evict the poison pill event and bring the display back up without it.

It's the not even 2nd rater who gives up on something which causes such a huge hole in the user experience, saying to themselves, "Uhhhh, there's no such thing as a never crash fix." You're not a 1st rate programmer if you only think one step ahead and say, "Uhhh, you can't guarantee no crashes," then leave such a huge hole in your system. The 1st rater engages in a bit of lateral thinking. The real problem isn't to eliminate crashes. The real problem is to eliminate the hole in the UX! Anything you can detect, you can "fix," and sometimes a guaranteed "fix" every bit as good or better.

(It's exactly this kind of mediocre thinking that led to the hardware quality doldrums in the 90's. The OS crashed so often, hardware manufacturers started to make cheap machines that could only stay up for a few days anyways.)

Re: Picking Apart the Crashing iOS String

#169

Post by m0th87 »

thezoq2 wrote: post #145
dom96 wrote: post #143

Earlier quoted context omitted.

Wouldn't any language with exceptions work here? You just define an indexing operator that throws an exception instead of crashing and handle that exception outside the unicode handling function.

The advantage of rusts error handling is that it is explicit. The compiler knows that a function might result in an error and forces the programmer to deal with it, or pass it along. In an exception based language you might forget to deal with the error and have it crash "higher up" in the code. I also suspect that there might be a performance benefit but I could be completely wrong about that

> The advantage of rusts error handling is that it is explicit. The compiler knows that a function might result in an error and forces the programmer to deal with it, or pass it along.

Checked exceptions are explicit as well, though I'm not aware of a language that _only_ has checked exceptions.

> I also suspect that there might be a performance benefit but I could be completely wrong about that

Yes, this is a big advantage. Stack unwinding is very expensive.

Re: Picking Apart the Crashing iOS String

#170

Post by t_heptapod »

kens wrote: post #38

Not directly related to the crash, but I have a question about Telugu and similar scripts: How do their speakers think about the structure of the script? Do they consider each vowel and consonant a separate "thing" that just happens to get written as a complex grapheme, or is the grapheme the unit you think about and it just happens to be made up of smaller parts? I.e https://en.wikipedia.org/wiki/Telugu_script#Conso…

As a telugu speaker, let me try answering you question.. The squiggly character you see has two characters joined The top and Bottom.. The top By itself can be used separately so It would be called "ja"

The bottom if used by itself would be called "na"

So basically the grapheme you see is made by joining to consonants Ja and na ..so it basically becomes "Jna" (spelt gna)

there are specific rules like english but like any language we have to learn these rules..eg I know that I can add k+ nowledge and that makes something in english..

But what if I add ra+no "rnoledge", yes you can add but that sounds weired, not sure if there is any rule which says you cannot add R+na, same with telugu.

Post reply on HN