4 ms·

There's this recurring problem with certain strings which crash the Messages app in iOS, leaving a big hole in functionality and making iOS look pretty bad. I'v

There's this recurring problem with certain strings which crash the Messages app in iOS, leaving a big hole in functionality and making iOS look pretty bad. I've pointed out that this is inexcusable for any language where you have exception handling. The standard reply to that on HN is to point out that you want the process to die once it's gone into undefined behavior, then downvote me. This puts me in mind of interviews, where I point out to the candidate that their update routine would go into an infinite loop if there was a 2 node cycle in their data. So then they give me an if statement that detects only the 2 node loop. I've even then asked what would happen if there was a 3 node loop, and gotten a 2nd if statement for that as well. Apps which might crash due to processing untrusted data should be reading that data from a queue. Then a 2nd process can monitor the 1st process, taking problematic data off the queue if necessary. This way the 1st process can die, but be restarted, and your smartphone OS doesn't have to look completely broken due to a primary function just dying, requiring the user to reboot. I hope someone tells me Apple has already done this. It's been something approaching a decade, at this point.

deaps 8y ago
I see where you're going - and I like the queue idea - but wouldn't it be better for that second function to just monitor the queue - and pull data off the queue that is problematic? Of course 'monitoring' is not exactly the same as 'processing' the actual data - so you'd have to know exactly what to pull off. Which would be just as easy to add that to the original process and just delete the unwanted data as you pull it out of the queue anyway. In either event, you seem fairly bright - I probably don't follow. The main thing is that I believe system processes do monitor those other processes and restart them if they crash - I think the problem comes in when data overflows or buffers spill out into other processes memory areas. ( I am not a programmer, although I do try to be for fun ).
- stcredzero 8y ago
  but wouldn't it be better for that second function to just monitor the queue - and pull data off the queue that is problematic? The most universal way to detect the problem is to catch the exception from the crash. However, the process that does that will be in the realm of undefined behavior, so it should be crashed. Of course 'monitoring' is not exactly the same as 'processing' the actual data - so you'd have to know exactly what to pull off. Your scheme is limited to all the known strings. My scheme can respond to anything in the future which might crash the 1st process.
charleslmunger 8y ago
I have no knowledge of apple's decisions here, and no experience with iOS, and you're generally correct that any sort of batch processing should be able to recover from bad input, but I'll try to make an argument as to why this isn't as simple as it sounds. 1. Creating a graceful degradation path is a complicated and expensive, from a UX, product, and testing perspective - if you silently drop the message, that's much worse than crashing; if you insert some sort of tombstone "this message could not be parsed" into the UI, you have to figure out if that's something users will actually understand. These code paths are hard to exercise with normal integration or manual testing, and it's likely that over time they may stop working correctly. 2. Monitoring graceful degradation is more complicated than tracking crashes, especially for unforeseen issues like what you're describing. There's a real risk that if this periodically showed up with "failed to parse" messages, the actual issue would have remained undiscovered by Apple a lot longer. 3. Again, no familiarity with iOS, but on other mobile operating systems I've worked with there's a significant memory overhead to using multiple processes and IPCs this way. If your device is under memory pressure, the extra cost of a pipeline like this introduces new failure modes. First, your other process may be killed by the LMK, which the sender process could interpret as being a failed message. Second, you may increase the amount of memory required to receive a text message in the background - this can directly affect critical high-memory use cases like taking a live video with the camera. There may just not be enough room to do both at the same time. 4. There's significant input processing that can't be done in another process, or meaningfully isolated from that of other messages - the best example being UI rendering of the text. If there's a magic string that causes view measurement to fail, that's extremely difficult to attribute to any specific piece of input - so adding this extra process to do validation won't really help you, since the "validated" string will fail later on.
- stcredzero 8y ago
  1. Is probably a lot more desirable than the smartphone OS looking like trash, requiring a reboot. iOS has suffered epidemics of people trolling by sending out messages that crash processes on other's phones. 2. Since this has happened several times at this point, the point is moot. Since this is familiar territory, why not log it and have the system tell HQ something weird happened? 3. May have been true in the past. Very doubtful at this point. 4. Irrelevant. The process can have the UI, crash, then be restarted by the other process. There is no validation done by the other process. The 2nd process only detects that the 1st process has crashed, then removes the offending datum from the queue.
someguydave 8y ago
Why not give up on Unicode and retreat back to reliably parsed simplified ASCII?

deaps 8y ago

I see where you're going - and I like the queue idea - but wouldn't it be better for that second function to just monitor the queue - and pull data off the queue that is problematic? Of course 'monitoring' is not exactly the same as 'processing' the actual data - so you'd have to know exactly what to pull off. Which would be just as easy to add that to the original process and just delete the unwanted data as you pull it out of the queue anyway. In either event, you seem fairly bright - I probably don't follow. The main thing is that I believe system processes do monitor those other processes and restart them if they crash - I think the problem comes in when data overflows or buffers spill out into other processes memory areas. ( I am not a programmer, although I do try to be for fun ).

stcredzero 8y ago
but wouldn't it be better for that second function to just monitor the queue - and pull data off the queue that is problematic? The most universal way to detect the problem is to catch the exception from the crash. However, the process that does that will be in the realm of undefined behavior, so it should be crashed. Of course 'monitoring' is not exactly the same as 'processing' the actual data - so you'd have to know exactly what to pull off. Your scheme is limited to all the known strings. My scheme can respond to anything in the future which might crash the 1st process.

charleslmunger 8y ago

I have no knowledge of apple's decisions here, and no experience with iOS, and you're generally correct that any sort of batch processing should be able to recover from bad input, but I'll try to make an argument as to why this isn't as simple as it sounds. 1. Creating a graceful degradation path is a complicated and expensive, from a UX, product, and testing perspective - if you silently drop the message, that's much worse than crashing; if you insert some sort of tombstone "this message could not be parsed" into the UI, you have to figure out if that's something users will actually understand. These code paths are hard to exercise with normal integration or manual testing, and it's likely that over time they may stop working correctly. 2. Monitoring graceful degradation is more complicated than tracking crashes, especially for unforeseen issues like what you're describing. There's a real risk that if this periodically showed up with "failed to parse" messages, the actual issue would have remained undiscovered by Apple a lot longer. 3. Again, no familiarity with iOS, but on other mobile operating systems I've worked with there's a significant memory overhead to using multiple processes and IPCs this way. If your device is under memory pressure, the extra cost of a pipeline like this introduces new failure modes. First, your other process may be killed by the LMK, which the sender process could interpret as being a failed message. Second, you may increase the amount of memory required to receive a text message in the background - this can directly affect critical high-memory use cases like taking a live video with the camera. There may just not be enough room to do both at the same time. 4. There's significant input processing that can't be done in another process, or meaningfully isolated from that of other messages - the best example being UI rendering of the text. If there's a magic string that causes view measurement to fail, that's extremely difficult to attribute to any specific piece of input - so adding this extra process to do validation won't really help you, since the "validated" string will fail later on.

stcredzero 8y ago
1. Is probably a lot more desirable than the smartphone OS looking like trash, requiring a reboot. iOS has suffered epidemics of people trolling by sending out messages that crash processes on other's phones. 2. Since this has happened several times at this point, the point is moot. Since this is familiar territory, why not log it and have the system tell HQ something weird happened? 3. May have been true in the past. Very doubtful at this point. 4. Irrelevant. The process can have the UI, crash, then be restarted by the other process. There is no validation done by the other process. The 2nd process only detects that the 1st process has crashed, then removes the offending datum from the queue.

someguydave 8y ago

Why not give up on Unicode and retreat back to reliably parsed simplified ASCII?