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

21–30 of 182 posts

Re: Picking Apart the Crashing iOS String

#21

Post by bonzini »

perkee wrote: post #19
ancarda wrote: post #14

Earlier quoted context omitted.

Do you know how was this bug found? Are there just enough people using iOS that these sorts of bugs can be found by mistake, or is someone fuzzing CoreText? Perhaps that can be applied to provide some kind of test coverage? Even if it’s not complete?

This sequence begins the Telugu word for "knowledge" so maybe someone texted that to someone and it went viral from there. This is, of course, only speculation.

Does the word include the zwnj character? How do you input it?

Re: Picking Apart the Crashing iOS String

#22

Post by nottorp »

spaceywilly wrote: post #5
brian-armstrong wrote: post #4

The broader question is, I think, how can any textual sequence cause a crash. Text should be regarded very skeptically by the text renderer. What could this be doing that it invokes a crash? Where else is this team not being careful? It reeks of process problems.

My question was, why was there not a unit test for this? It seems like it would be trivial to step through every character combination for each language they support and make sure it doesn't cause a crash.

I bet they have unit tests for all emojis...

Re: Picking Apart the Crashing iOS String

#23

Post by jcranmer »

Diggsey wrote: post #11

My guess would be that it's some aspect of measuring the text that is causing the crash: when you click in an editable text box, there is code to track down where the cursor should be placed. This is done by measuring various sub-strings of the whole line. If measuring the sub-strings gives surprising results (sub-strings being visibly longer for example), this could cause the algorithm to fail in any number of inter…

I'd have to dump strings as grapheme clusters, but it's quite possible that there's some grapheme cluster weirdness going on here.

Re: Picking Apart the Crashing iOS String

#24

Post by Sir_Cmpwn »

kibwen wrote: post #12

Has anyone yet traced this to a specific syscall? Seems like the perfect opportunity for whipping up a fuzzer to spit arbitrary unicode into the system and see what else crashes.

I doubt very seriously that a misbehaving syscall is involved in the crash.

Re: Picking Apart the Crashing iOS String

#25

Post by enzanki_ars »

kibwen wrote: post #12

Has anyone yet traced this to a specific syscall? Seems like the perfect opportunity for whipping up a fuzzer to spit arbitrary unicode into the system and see what else crashes.

Would that even be possible on iOS for non Apple employees?

My idea would be just to create a program that continually creates Unicode strings and display them on screen with a pause before creating and displaying the next. Record the screen and see if any thing exciting happens. Would never end, if there was a SETI @ Home style program for it with insentives for running it would be cool.

Re: Picking Apart the Crashing iOS String

#26

Post by Manishearth »

bitwize wrote: post #17
Manishearth wrote: post #3

Earlier quoted context omitted.

You want "multi-codepoint graphemes" probably. Or really "things involving combining characters". There isn't really a term for this.

I believe the Unicode term is "grapheme cluster".

Not exactly, no.

क्र is currently not a grapheme cluster, for example (there is a proposed change to UAX 29 to make it such, but that doesn't handle all such cases).

The strings in this situation are three grapheme clusters according to the spec even though they usually render as a single "thingy".

Re: Picking Apart the Crashing iOS String

#27

Post by sigjuice »

kibwen wrote: post #12

Has anyone yet traced this to a specific syscall? Seems like the perfect opportunity for whipping up a fuzzer to spit arbitrary unicode into the system and see what else crashes.

Most likely none of this involves syscalls directly. Are there any syscalls that concern themselves with unicode, besides perhaps filesystem related syscalls?

Re: Picking Apart the Crashing iOS String

#28

Post by Manishearth »

Diggsey wrote: post #11

My guess would be that it's some aspect of measuring the text that is causing the crash: when you click in an editable text box, there is code to track down where the cursor should be placed. This is done by measuring various sub-strings of the whole line. If measuring the sub-strings gives surprising results (sub-strings being visibly longer for example), this could cause the algorithm to fail in any number of inter…

Well, the crash occurs for Spotlight without me clicking anything or having any cursors anywhere.

But yeah, this is one of my theories about it. One of the previous crashes had to do with an Arabic string which got longer when you truncated it, which made snipping it to display in a notification have bugs.

It's interesting to see it's causing a segfault, i'd expect measuring bugs to cause clean assertions or shitty rendering. Which is why I'm also wondering if it's actually a disagreement on the number of "characters" in the rendered things.

> If measuring the sub-strings gives surprising results (sub-strings being visibly longer for example), this could cause the algorithm to fail in any number of interesting ways: for example if a binary search is used to locate the cursor position, it could break the invariants of the binary search.

Cursor positions are based off of grapheme clusters -- there's a defined algorithm for that. Though different parts of the system may disagree on the specifics of the algorithm causing such a crash.

However, that doesn't gel with the fact that it's only specific consonants causing this, all versions of UAX 29 do not consider any differences between Indic consonants for a single given script.

Re: Picking Apart the Crashing iOS String

#29

Post by jfk13 »

goalieca wrote: post #20
Diggsey wrote: post #11

My guess would be that it's some aspect of measuring the text that is causing the crash: when you click in an editable text box, there is code to track down where the cursor should be placed. This is done by measuring various sub-strings of the whole line. If measuring the sub-strings gives surprising results (sub-strings being visibly longer for example), this could cause the algorithm to fail in any number of inter…

I believe the renderer is a brand new metal 2 for high sierra. The crashing 3rd party apps for iOS are using this new rendering too?

It can crash on (non-high) Sierra, too. The crash is in Core Text shaping, rather than in actual painting, so somewhat above the metal level IIUC.

Re: Picking Apart the Crashing iOS String

#30

Post by minimaxir »

brian-armstrong wrote: post #4

The broader question is, I think, how can any textual sequence cause a crash. Text should be regarded very skeptically by the text renderer. What could this be doing that it invokes a crash? Where else is this team not being careful? It reeks of process problems.

A good example of test sequences causing weird behavior/crashes are RTL languages (like Hebrew and Arabic) and CJK characters (Chinese/Japanese/Korean), which have UI implications as well.

While working at Apple in Software QA, both of these cases in part inspired me to create the Big List of Naughty Strings years ago: https://github.com/minimaxir/big-list-of-naughty-strings

Post reply on HN