6 ms·

This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we should

This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.

bla2 9y ago
More like "this is why we should use LLVM's libFuzzer or similar". Apple is just not doing basic code hygiene stuff here.
- TazeTSchnitzel 9y ago
  Fuzzing finds bugs, using a safe language precludes them.
  - virgilp 9y ago
    No it doesn't. At best it precludes a certain class of bugs (which may be very significant, but it's not a silver bullet)
    - taf2 9y ago
      var stack = []; function ThisWillNeverCrash() { console.log('hello'); stack.push('it'); setTimeout(ThisWillNeverCrash, 0); } setTimeout(ThisWillNeverCrash, 0); // my point in posting this was to demonstrate a bug ... that array will eventually run out of memory and this loops infinitely but not using a standard language loop construct... but I see someone didn’t think that was relevant
  - vlovich123 9y ago
    What constitutes a safe language? Is Rust safe?
    - steveklabnik 9y ago
      Not by the parent's definition, anyway. Rust code certainly has bugs; I know, I've written some! Now, if they're talking about memory safety bugs...
- eridius 9y ago
  Apple has been known to fuzz their code. Just because they didn't uncover this particular bug doesn't mean they didn't do any fuzzing, it just means the fuzzing didn't hit this case.
nebula 9y ago
I checked the character, it is anything but weird. It is a valid character in a language used by millions of people. For those curious: It is a Telugu character; Telugu is one of several widely spoken languages in India.
- Manishearth 9y ago
  The ZWNJ is definitely weird -- ZWNJ on Telugu isn't really useful. However the crash also occurs with a Bengali sequence, and ZWNJ does have an effect in Bengali, so that sequence is not "weird", if perhaps rare.
- reaperducer 9y ago
  I guess it depends on your definition of "widely spoken." According to Wikipedia, the number of people speaking Telugu is 0.97% of the world. It's not even a statistical margin of error. Still, how hard can it be to have a machine step through all of the possible combinations of every iOS-supported character set and jam them into iMessage to see if they're failsafe? [1]: https://en.wikipedia.org/wiki/Telugu_language https://en.wikipedia.org/wiki/Telugu_language
  - lostmsu 9y ago
    1%? Are you kidding? That's over 70 million. It's on the order of population of Germany, and 10 times more, than Swedes.
    - bluntfang 9y ago
      i think the metric isn't the right one. 1% is a small user base, but of that 1% how many of them have access to iphones?
ksk 9y ago
>This is why we shouldn't be writing new code in C. Depends on your priorities. I'd take occasional bugs over jitter, latency, CPU inefficiency, and excess memory usage. And all that in practical terms means C is very environmentally friendly.
- iknowstuff 9y ago
  Choose Rust. It has zero-overhead memory and data race safety.
  - ksk 9y ago
    I suppose so. As an embedded developer it appeals to me, but I haven't looked too much into it TBH. Do you know of any analysis done on the bugs in servo or any other large-ish project?
    - iknowstuff 9y ago
      I haven't studied this extensively, but Mozilla made the following claim: >Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical! https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
      - ksk 9y ago
        Right, I just wanted to examine it in the 'proof is in the pudding' sense where if Rust is as good as people claim, then certain types of bugs would be entirely eliminated. I'm usually weary of such claims :)
badgers 9y ago
We need a new "Falsehoods programmers believe about character encodings" article to be added to the falsehoods list [1]. Joel Spolsky wrote in 2003 about the dangers of the ignorance of character encodings [2]. [1] - https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood [2] - https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...
makecheck 9y ago
There are compartmentalization options, such as XPC Services on macOS (specialized sub-processes that can “crash” if something is risky). Also, non-C languages frequently implement lots of library features on top of C because it would be a ton of work not to (and slower), which means any language could be at risk.
andrewmcwatters 9y ago
What causes this to be an issue in C but not in other languages?
- Someone1234 9y ago
  It is in other languages just to be clear. C++ for one example could suffer from it. But largely the issue is, when an error occurs, can the state change to [undefined]. In some languages, like C/C++, it is possible through bugs to enter an undefined state. In many higher level languages, all states are defined even if not all states are actually handled by the developer's code. If all states are defined you can use tooling to look for states which aren't handled by any execution path, and ideally handle them. If they remain unhandled there is a documented way to handle the unhandled known state (e.g. global exception handlers). In a language with undefined states that isn't possible, all you can do is look for areas likely to result in an undefined state, but even that is easier said than done. Higher level languages save you from a few classes of bugs, and make it easier to find bugs because things are more narrowly defined.
  - payonel 9y ago
    This is one of the most painfully ignorant things I have ever read. There is absolutely no such thing as "all states are defined". This has nothing to do with the language. There is nothing magical about a "higher level language" to safeguard from failures. At best you could be referring to managed languages, where memory access and exceptions are controlled and the extent of a aborted execution is predetermined - but still not immune to just closing a process when they misbehave. That is precisely what a process should do. Nonetheless, nothing in this bug report indicates that the system is acting in an undefined manner. The library that failed may have, by design, been programmed to close when font rendering reached these conditions. We don't know if this was a signal abort or an intentional if (bad_outcome) close() Any level from the most managed sandboxed level to the most host level process may fail, regardless of the language used.

This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.

bla2 9y ago

More like "this is why we should use LLVM's libFuzzer or similar". Apple is just not doing basic code hygiene stuff here.

TazeTSchnitzel 9y ago
Fuzzing finds bugs, using a safe language precludes them.
- virgilp 9y ago
  No it doesn't. At best it precludes a certain class of bugs (which may be very significant, but it's not a silver bullet)
  - taf2 9y ago
    var stack = []; function ThisWillNeverCrash() { console.log('hello'); stack.push('it'); setTimeout(ThisWillNeverCrash, 0); } setTimeout(ThisWillNeverCrash, 0); // my point in posting this was to demonstrate a bug ... that array will eventually run out of memory and this loops infinitely but not using a standard language loop construct... but I see someone didn’t think that was relevant
- vlovich123 9y ago
  What constitutes a safe language? Is Rust safe?
  - steveklabnik 9y ago
    Not by the parent's definition, anyway. Rust code certainly has bugs; I know, I've written some! Now, if they're talking about memory safety bugs...
eridius 9y ago
Apple has been known to fuzz their code. Just because they didn't uncover this particular bug doesn't mean they didn't do any fuzzing, it just means the fuzzing didn't hit this case.

nebula 9y ago

I checked the character, it is anything but weird. It is a valid character in a language used by millions of people. For those curious: It is a Telugu character; Telugu is one of several widely spoken languages in India.

Manishearth 9y ago
The ZWNJ is definitely weird -- ZWNJ on Telugu isn't really useful. However the crash also occurs with a Bengali sequence, and ZWNJ does have an effect in Bengali, so that sequence is not "weird", if perhaps rare.
reaperducer 9y ago
I guess it depends on your definition of "widely spoken." According to Wikipedia, the number of people speaking Telugu is 0.97% of the world. It's not even a statistical margin of error. Still, how hard can it be to have a machine step through all of the possible combinations of every iOS-supported character set and jam them into iMessage to see if they're failsafe? [1]: https://en.wikipedia.org/wiki/Telugu_language https://en.wikipedia.org/wiki/Telugu_language
- lostmsu 9y ago
  1%? Are you kidding? That's over 70 million. It's on the order of population of Germany, and 10 times more, than Swedes.
  - bluntfang 9y ago
    i think the metric isn't the right one. 1% is a small user base, but of that 1% how many of them have access to iphones?

ksk 9y ago

>This is why we shouldn't be writing new code in C. Depends on your priorities. I'd take occasional bugs over jitter, latency, CPU inefficiency, and excess memory usage. And all that in practical terms means C is very environmentally friendly.

iknowstuff 9y ago
Choose Rust. It has zero-overhead memory and data race safety.
- ksk 9y ago
  I suppose so. As an embedded developer it appeals to me, but I haven't looked too much into it TBH. Do you know of any analysis done on the bugs in servo or any other large-ish project?
  - iknowstuff 9y ago
    I haven't studied this extensively, but Mozilla made the following claim: >Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical! https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
    - ksk 9y ago
      Right, I just wanted to examine it in the 'proof is in the pudding' sense where if Rust is as good as people claim, then certain types of bugs would be entirely eliminated. I'm usually weary of such claims :)

badgers 9y ago

We need a new "Falsehoods programmers believe about character encodings" article to be added to the falsehoods list [1]. Joel Spolsky wrote in 2003 about the dangers of the ignorance of character encodings [2]. [1] - https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood [2] - https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...

makecheck 9y ago

There are compartmentalization options, such as XPC Services on macOS (specialized sub-processes that can “crash” if something is risky). Also, non-C languages frequently implement lots of library features on top of C because it would be a ton of work not to (and slower), which means any language could be at risk.

andrewmcwatters 9y ago

What causes this to be an issue in C but not in other languages?

Someone1234 9y ago
It is in other languages just to be clear. C++ for one example could suffer from it. But largely the issue is, when an error occurs, can the state change to [undefined]. In some languages, like C/C++, it is possible through bugs to enter an undefined state. In many higher level languages, all states are defined even if not all states are actually handled by the developer's code. If all states are defined you can use tooling to look for states which aren't handled by any execution path, and ideally handle them. If they remain unhandled there is a documented way to handle the unhandled known state (e.g. global exception handlers). In a language with undefined states that isn't possible, all you can do is look for areas likely to result in an undefined state, but even that is easier said than done. Higher level languages save you from a few classes of bugs, and make it easier to find bugs because things are more narrowly defined.
- payonel 9y ago
  This is one of the most painfully ignorant things I have ever read. There is absolutely no such thing as "all states are defined". This has nothing to do with the language. There is nothing magical about a "higher level language" to safeguard from failures. At best you could be referring to managed languages, where memory access and exceptions are controlled and the extent of a aborted execution is predetermined - but still not immune to just closing a process when they misbehave. That is precisely what a process should do. Nonetheless, nothing in this bug report indicates that the system is acting in an undefined manner. The library that failed may have, by design, been programmed to close when font rendering reached these conditions. We don't know if this was a signal abort or an intentional if (bad_outcome) close() Any level from the most managed sandboxed level to the most host level process may fail, regardless of the language used.