4 ms·

There is more complexity in this. Proximate Issues The app makers cannot easily prevent the crash since it is happening in Facebook provided code. Perhaps the

by babesh 6y ago

There is more complexity in this. Proximate Issues The app makers cannot easily prevent the crash since it is happening in Facebook provided code. Perhaps the only thing they could do is to code in kill switches. Another possibility would be to modify the Facebook code. That introduces maintainability issues. The crash happened because of a server side change that triggered roughly the Objective-C equivalent of a null pointer exception. Objective-C is an old unsafe language. Ultimate Issues Client-side libraries have a poor history in the industry. They are often written by server engineers who aren’t expert on the platform. For instance, if it was really a static load method that called the server, then this was a poor design decision. Furthermore, weaker server engineers are notorious for breaking backward compatibility. They don’t design nor build in tests to ensure backward compatibility. The backward compatibility must include backward data compatibility. The above issues are indicative of organizational issues. Facebook is a little bit of an outlier. It was notorious for badly written client libraries stretching back to the Facebook platform days. The joke was that their libraries may have been written by interns even though so many companies were dependent on them. The Facebook libraries and the ilk are used for sign on through Facebook and ad attribution. The trade off an app maker needs to make it a whether to run ads on Facebook and whether to support sign in. Facebook is not the only big company with these issues. Google’s equivalent also crashed albeit at a much lower rate due to a much more convoluted issue. Apple introduced the Swift programming language to address the deficiencies in Objective-C. That these companies are running into these issues makes me wonder if they never transitioned to Swift. They are certainly way behind the latest version of the libraries. To summarize, it is a cascade of issues some technical and some organizational rather than a single coding error. These issues span companies.

saagarjha 6y ago
> The crash happened because of a server side change that triggered roughly the Objective-C equivalent of a null pointer exception. > Objective-C is an old unsafe language. This was a safe crash, not an unsafe one. Swift can and would crash the same way.
- babesh 6y ago
  You can’t safely call a method on a nil value in Swift. You need to explicitly force that in your code with an exclamation point to assume that the variable is not nil. Looks like the server passed empty value in JSON which got converted to NSNull in Objective-C. It's a common mistake to assume null is returned instead of NSNull. The Swift equivalent of the JSON library should return nil which you then need to explicitly check for non nilness before using unless you use the unsafe exclamation pint.
  - saagarjha 6y ago
    $ swift Welcome to Apple Swift version 5.3 (swiftlang-1200.0.16.15 clang-1200.0.22.41). Type :help for assistance. 1> import Foundation 2> // IIRC this used to throw an exception. 3> // Now a respondsToSelector: check is silently inserted and we get a surprise nil. 4> (Int?.none as AnyObject).count + "call Swift's bluff".count Fatal error: Unexpectedly found nil while unwrapping an Optional value: file repl.swift, line 4 2020-07-10 18:03:43.815959-0700 repl_swift[73029:930570] Fatal error: Unexpectedly found nil while unwrapping an Optional value: file repl.swift, line 4 Execution interrupted. Enter code to recover and continue. Enter LLDB commands to investigate (type :help for assistance.)
    - babesh 6y ago
      You need to call Swift's bluff with AnyObject. That's unsafe and was only necessary to bridge to Objective-C where you can call any method on any object. I think we are in general agreement?
      - saagarjha 6y ago
        When you write an iOS app you're constantly interacting with Objective-C. The moment you're using JSONSerialization–and unless you're shipping your own JSON parser, you're not avoiding it–you're getting back a nice Any that you are almost certainly going to work with, possibly implicitly, using AnyObject. My point was that switching the SDK to use Swift would not help fix this issue, and I think I've shown that you'd run into similar issues even without the use of the force unwrap operator as you implied previously.
kobalsky 6y ago
Google has recently pushed a payload that crashed any app using Google Maps SDK https://issuetracker.google.com/issues/154855417 https://issuetracker.google.com/issues/154855417 This one was a good one because the app cache was poisoned so the only solution was to ask customers to reinstall the app (after Google deployed their fix, which took a while) or upload an update that nuked the SDK cache on startup.

by babesh 6y ago

saagarjha 6y ago

> The crash happened because of a server side change that triggered roughly the Objective-C equivalent of a null pointer exception. > Objective-C is an old unsafe language. This was a safe crash, not an unsafe one. Swift can and would crash the same way.

babesh 6y ago
You can’t safely call a method on a nil value in Swift. You need to explicitly force that in your code with an exclamation point to assume that the variable is not nil. Looks like the server passed empty value in JSON which got converted to NSNull in Objective-C. It's a common mistake to assume null is returned instead of NSNull. The Swift equivalent of the JSON library should return nil which you then need to explicitly check for non nilness before using unless you use the unsafe exclamation pint.
- saagarjha 6y ago
  $ swift Welcome to Apple Swift version 5.3 (swiftlang-1200.0.16.15 clang-1200.0.22.41). Type :help for assistance. 1> import Foundation 2> // IIRC this used to throw an exception. 3> // Now a respondsToSelector: check is silently inserted and we get a surprise nil. 4> (Int?.none as AnyObject).count + "call Swift's bluff".count Fatal error: Unexpectedly found nil while unwrapping an Optional value: file repl.swift, line 4 2020-07-10 18:03:43.815959-0700 repl_swift[73029:930570] Fatal error: Unexpectedly found nil while unwrapping an Optional value: file repl.swift, line 4 Execution interrupted. Enter code to recover and continue. Enter LLDB commands to investigate (type :help for assistance.)
  - babesh 6y ago
    You need to call Swift's bluff with AnyObject. That's unsafe and was only necessary to bridge to Objective-C where you can call any method on any object. I think we are in general agreement?
    - saagarjha 6y ago
      When you write an iOS app you're constantly interacting with Objective-C. The moment you're using JSONSerialization–and unless you're shipping your own JSON parser, you're not avoiding it–you're getting back a nice Any that you are almost certainly going to work with, possibly implicitly, using AnyObject. My point was that switching the SDK to use Swift would not help fix this issue, and I think I've shown that you'd run into similar issues even without the use of the force unwrap operator as you implied previously.

kobalsky 6y ago

Google has recently pushed a payload that crashed any app using Google Maps SDK https://issuetracker.google.com/issues/154855417 https://issuetracker.google.com/issues/154855417 This one was a good one because the app cache was poisoned so the only solution was to ask customers to reinstall the app (after Google deployed their fix, which took a while) or upload an update that nuked the SDK cache on startup.