7 ms·

The crash seems to be in CoreText. CoreText is embedded/linked in Messages, Spotlight, Springboard, etc. CoreText is written in C. The fix would be to rewrit

by pkaler 9y ago

The crash seems to be in CoreText. CoreText is embedded/linked in Messages, Spotlight, Springboard, etc. CoreText is written in C. The fix would be to rewrite CoreText in a memory safe language like Swift. This would be “hard”. Or put CoreText in an XPC container. This would both be “hard” and result in terrible performance. For more details on how hard C, memory management, systems programming, and operating system development is please refer to your local copy of Modern Operating Systems by Andy Tannenbaum.

mapmap 9y ago
I'm guessing C is how they get the performance they need. Re-writing in Obj-C or Swift would likely have speed tradeoffs.
- ams6110 9y ago
  Obj-C is C, or more accurately a superset of it.
- justAnotherNET 9y ago
  Sure, but would it crash the entire OS when there’s a problem?
- pjmlp 9y ago
  C code only got fast thanks to 40 years of optimizer improvements, taking advantage of UB.
  - zxxon 9y ago
    Huh? C is fast (compared to Swift) because using it doesn't imply sprinkling lots of sugar (like ARC) into the resulting machine code. Simpler languages like Fortran can turn into even faster code than a C implementation. UB optimizations aren't that relevant for real-world performance.
    - pjmlp 9y ago
      Code generated by C compilers is fast in 2018. Code generated by C compilers for C64, Spectrum, Atari, Atari ST, Amiga, Mac, CP/M, MS-DOS, Windows 3.x, Nintendo, MegaDrive,... systems meant many times the code would be 80% like this: void some_func(/* params */) { asm { /* actual "C" code as inline Assembly */ } } Lots of Swift sugar also gets optimized away, and there is plenty of room to improvement. The code that current C compilers don't generate, many times is related to taking advantage of UB. They also generate extra code for handling stuff like floating point emulation though. Just as an example, IBM did their whole RISC research using PL/8, including an OS and optimizing compiler using an architecture similar to what LLVM uses. They only bothered with C, after making the business case that RISC would be a good platform for UNIX workstations.
      - zxxon 9y ago
        Why bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly. >> The code that current C compilers don't generate, many times is related to taking advantage of UB Compilers are really smart in optimizing things that aren't relevant to the real world. For example, this code would reduce to "return 32" in most modern compilers: int return32(){ int x=1; for (int i=0; i<5; i++){ x*=2; } return x; } Does that make impact in real-world code? Almost certainly not, it's a contrived case. Most UB cases fall into the same category. >> They also generate extra code for handling stuff like floating point emulation though. Not necessarily.
        pjmlp 9y ago
        > wWhy bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly. To clear up the myth among young generations that C compilers always generated fast code, regardless of the platform. As for something more modern, in 1998, C code quality was still at a similar level to other system's languages, before they started to fade away thanks to the increase in UNIX, Linux and BSD adoption For example, given that Delphi and C++ Builder share the same backend, their generated code was quite similar, even if it would require disabling some of the Delphi's security checks. > Not necessarily. Sure, it all depends on the CPU being targeted.
cek 9y ago
Putting a buggy system in a memory safe environment is certainly not 'the fix'. The fix is to find the precise bug or architectural deficiency and fix it.
- raverbashing 9y ago
  It's easier to failsafe something than make things perfect Even better, when you failsafe you plan for the (unknown) future. That's why we have circuit breakers, hydraulic and electric fuses, pressure relief valves, etc. Because no one thinks they can know all things that can go wrong in the future (with catastrophic consequences) and plan for that
  - defined 9y ago
    That’s the reasoning behind the Erlang “let it crash” philosophy. It’s not advocating poor programming; it’s asking processes to handle whatever issues they can within reason, but otherwise to crash and be restarted by their supervisor process, rather than try to carry on in a probably erroneous state. It’s also a recognition that in complex systems, something unanticipated is going to go wrong sometimes, and rather have a plan for handling the failure than pretend that the system will never hit a really bizarre failure mode. Your circuit breaker analogy made me think of this.
gurkendoktor 9y ago
It's harder than that. Even if you sandbox the code, then it could still happen that some particularly wacky layout code never terminates.
nitwit005 9y ago
There are usually less dramatic fixes like changing all the array accesses to be checked, or putting pages that will trigger a fault around the buffers that the library uses, and handling the fault hitting those buffers generates.
- justAnotherNET 9y ago
  Or you could just be the richest company in the world like Apple and pay market rates to top talent to invest in your architecture. I’m rapidly losing patience with major companies posting record profits next to unprecedented software calamities. It starts and ends with an elite corporate culture that doesn’t value what we do.
Someone1234 9y ago
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 current situation. Obviously we'd all like bug free fonts and text rendering, but if we call that goal aspirational (read: impossible), the best we can hope for today is handling the fault cases better than they're handled today. Bootloops are a pretty lame user experience.
- lloeki 9y ago
  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.
  - semi-extrinsic 9y ago
    That's right, there's no kernel crash AFAICT. Pissed my niece the hell off though, that I could remotely disable her Messenger.
    - logicallee 9y ago
      Well she's right to be pissed if you did that. On the other hand I had the same thought (but better self-restraint than you) - however I was thinking "nah, scrubbing bad messages server side is just an s/badstring// and I am sure the major non-encrypted messenger apps (where the server knows the strings) added that server-side, so people couldn't crash their contacts' apps, which the app company might get blamed for. This kind of hotfix shouldn't have negative effects, I'm sure there are already a few server-side manipulations of text (stuff like adding a space to very long lines, maybe a blacklist of certain malicious URL's that sort of thing.) So I'm surprised your message was delivered as sent (if it's not encrypted end to end), unless you did this right when the news broke.

by pkaler 9y ago

mapmap 9y ago

I'm guessing C is how they get the performance they need. Re-writing in Obj-C or Swift would likely have speed tradeoffs.

ams6110 9y ago
Obj-C is C, or more accurately a superset of it.
justAnotherNET 9y ago
Sure, but would it crash the entire OS when there’s a problem?
pjmlp 9y ago
C code only got fast thanks to 40 years of optimizer improvements, taking advantage of UB.
- zxxon 9y ago
  Huh? C is fast (compared to Swift) because using it doesn't imply sprinkling lots of sugar (like ARC) into the resulting machine code. Simpler languages like Fortran can turn into even faster code than a C implementation. UB optimizations aren't that relevant for real-world performance.
  - pjmlp 9y ago
    Code generated by C compilers is fast in 2018. Code generated by C compilers for C64, Spectrum, Atari, Atari ST, Amiga, Mac, CP/M, MS-DOS, Windows 3.x, Nintendo, MegaDrive,... systems meant many times the code would be 80% like this: void some_func(/* params */) { asm { /* actual "C" code as inline Assembly */ } } Lots of Swift sugar also gets optimized away, and there is plenty of room to improvement. The code that current C compilers don't generate, many times is related to taking advantage of UB. They also generate extra code for handling stuff like floating point emulation though. Just as an example, IBM did their whole RISC research using PL/8, including an OS and optimizing compiler using an architecture similar to what LLVM uses. They only bothered with C, after making the business case that RISC would be a good platform for UNIX workstations.
    - zxxon 9y ago
      Why bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly. >> The code that current C compilers don't generate, many times is related to taking advantage of UB Compilers are really smart in optimizing things that aren't relevant to the real world. For example, this code would reduce to "return 32" in most modern compilers: int return32(){ int x=1; for (int i=0; i<5; i++){ x*=2; } return x; } Does that make impact in real-world code? Almost certainly not, it's a contrived case. Most UB cases fall into the same category. >> They also generate extra code for handling stuff like floating point emulation though. Not necessarily.
      - pjmlp 9y ago
        > wWhy bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly. To clear up the myth among young generations that C compilers always generated fast code, regardless of the platform. As for something more modern, in 1998, C code quality was still at a similar level to other system's languages, before they started to fade away thanks to the increase in UNIX, Linux and BSD adoption For example, given that Delphi and C++ Builder share the same backend, their generated code was quite similar, even if it would require disabling some of the Delphi's security checks. > Not necessarily. Sure, it all depends on the CPU being targeted.

cek 9y ago

Putting a buggy system in a memory safe environment is certainly not 'the fix'. The fix is to find the precise bug or architectural deficiency and fix it.

raverbashing 9y ago
It's easier to failsafe something than make things perfect Even better, when you failsafe you plan for the (unknown) future. That's why we have circuit breakers, hydraulic and electric fuses, pressure relief valves, etc. Because no one thinks they can know all things that can go wrong in the future (with catastrophic consequences) and plan for that
- defined 9y ago
  That’s the reasoning behind the Erlang “let it crash” philosophy. It’s not advocating poor programming; it’s asking processes to handle whatever issues they can within reason, but otherwise to crash and be restarted by their supervisor process, rather than try to carry on in a probably erroneous state. It’s also a recognition that in complex systems, something unanticipated is going to go wrong sometimes, and rather have a plan for handling the failure than pretend that the system will never hit a really bizarre failure mode. Your circuit breaker analogy made me think of this.

gurkendoktor 9y ago

It's harder than that. Even if you sandbox the code, then it could still happen that some particularly wacky layout code never terminates.

nitwit005 9y ago

There are usually less dramatic fixes like changing all the array accesses to be checked, or putting pages that will trigger a fault around the buffers that the library uses, and handling the fault hitting those buffers generates.

justAnotherNET 9y ago
Or you could just be the richest company in the world like Apple and pay market rates to top talent to invest in your architecture. I’m rapidly losing patience with major companies posting record profits next to unprecedented software calamities. It starts and ends with an elite corporate culture that doesn’t value what we do.

Someone1234 9y ago

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 current situation. Obviously we'd all like bug free fonts and text rendering, but if we call that goal aspirational (read: impossible), the best we can hope for today is handling the fault cases better than they're handled today. Bootloops are a pretty lame user experience.

lloeki 9y ago
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.
- semi-extrinsic 9y ago
  That's right, there's no kernel crash AFAICT. Pissed my niece the hell off though, that I could remotely disable her Messenger.
  - logicallee 9y ago
    Well she's right to be pissed if you did that. On the other hand I had the same thought (but better self-restraint than you) - however I was thinking "nah, scrubbing bad messages server side is just an s/badstring// and I am sure the major non-encrypted messenger apps (where the server knows the strings) added that server-side, so people couldn't crash their contacts' apps, which the app company might get blamed for. This kind of hotfix shouldn't have negative effects, I'm sure there are already a few server-side manipulations of text (stuff like adding a space to very long lines, maybe a blacklist of certain malicious URL's that sort of thing.) So I'm surprised your message was delivered as sent (if it's not encrypted end to end), unless you did this right when the news broke.