4 ms·

Yes - I understand HOW it happened, just not sure WHY. Meaning, I'm not sure what the developer was thinking, and at this point, I'm not going to track down exa

Yes - I understand HOW it happened, just not sure WHY. Meaning, I'm not sure what the developer was thinking, and at this point, I'm not going to track down exactly who it was and point fingers. I think everyone has learned enough through this highly interesting bug. It certainly was interesting to see the slack room exploding with theories and debugging. A new iOS client has been submitted to Apple (hurry plz!!!), and a server fix is also in QA now. Fun problems to have......

ww520 9y ago
It's most likely for efficiency and performance reason. 64-bit doubles the storage requirement of 32-bit and would have impact on database's utilization of memory, querying window size, cache, and storage. Edit: 32 bits worth of games played means about 4 billion games. 4 billion X 4 bytes for 32-bit = 16GB just for the 32-bit ID's. 64-bit ID's would need 32GB for the 4 billion games. I guess memory and storage weren't that cheap back then.
- mikeash 9y ago
  It sounds like it was client side, not server side. Most likely the iOS client was using Objective-C's NSInteger or Swift's Int, just because that's the default choice for most programmers working in that language, and they didn't think it through.
- markcerqueira 9y ago
  It also could've been just the person picking an int over a long. Is ints vs. longs the first place to look for optimizing efficiency/performance?
  - cesarb 9y ago
    On a 32-bit system, a "long" is usually also 32 bits. On a non-Microsoft 64-bit system, a "long" is usually 64 bits. On both 32-bit and 64-bit systems (Microsoft or not), an "int" is usually 32 bits. If the issue happened only on 32-bit iPads, but not on 64-bit iPads, the programmer probably picked a "long", not an "int". Had the programmer picked an "int", the problem would also happen on 64-bit iPads.
    - e28eta 9y ago
      Our iOS app with Java backend was using long for database IDs on both ends. I was going through the ILP32->LP64 conversion process and when I realized we had a pretty serious discrepancy. I think it's a really easy mistake for the first developer to make (especially because they weren't a C/Obj-C programmer), and then the sort of thing that no one audits after that.
      - cesarb 9y ago
        Yeah, Java always uses 64 bits for "long", even on 32-bit systems. Which only adds to the confusion, since it's different from C and C++. (Another place where Java is confusingly different: "volatile" implies a memory barrier in Java, but not in C and C++.)
creepydata 9y ago
This is an fairly easy mistake to make for a novice developer to make. It even has a specific name - integer overflow - https://en.wikipedia.org/wiki/Integer_overflow https://en.wikipedia.org/wiki/Integer_overflow The original Pacman crashes at level 256 for the same reason. - http://pacman.wikia.com/wiki/Map_256_Glitch http://pacman.wikia.com/wiki/Map_256_Glitch
wvenable 9y ago
> Meaning, I'm not sure what the developer was thinking A 32bit integer is pretty much the default numeric type for the majority of programming tasks over the last 20 years. Even with 64bit CPUs, 32bit is still a common practice. Probably 99% of all programmers would make the same choice unless given specific requirements to support more than 2 billion values.
- xapata 9y ago
  > 99% of all programmers Many dynamically typed languages have an automatic change from int to bigint rather than allowing overflow. For example, Python.
  - mort96 9y ago
    Others, like JS and Lua, just use doubles, meaning they'll never overflow - instead every 2 numbers start to be considered equal. Then a while after that every 4, etc. Not exactly optimal behavior when using incrementing IDs.
    - tripzilch 9y ago
      however, doubles represent integers accurately up to 53 bits. so that's still quite a lot before you run into that problem.
- ewjordan 9y ago
  It's often not even an explicit choice, it's just default behavior. Up until recently, Rails defaulted to 32 bit IDs, so there are a ton of apps out there that could have these issues, especially since Rails has always prided itself on providing sane defaults: https://github.com/rails/rails/pull/26266 https://github.com/rails/rails/pull/26266
sundvor 9y ago
As a consolation: Over 2 billion games played - congratulations!
qqg3 9y ago
I don't think you do understand, you sound like you're upset that a developer "set" this limit. When in reality it's tied to fundamental programming principles. It wasn't really a conscious decision to say, "I'm only going to account for 2bil games"...
mcv 9y ago
Probably when this was initially developed, nobody thought you'd ever go over 2 billion games. This error is brought to light by your success and popularity. Computer history is riddled with assumptions like that. The Y2K problem, Unix dates running out in 2037, and 32 bit computers unable to address more than 4 GB of memory are just the big ones. It's everywhere. Smaller software projects are generally built for what you need right now, and less for what might happen in the distant future. Ideally you want to retain some awareness that this is an issue so you can start working on once you go over a billion games, but in a small company, there are probably always more urgent things to worry about, and nobody ever gets around to fixing this technical debt.
obj-g 9y ago
> Meaning, I'm not sure what the developer was thinking, and at this point, I'm not going to track down exactly who it was and point fingers. As a developer, this sentence made my skin crawl.

ww520 9y ago

It's most likely for efficiency and performance reason. 64-bit doubles the storage requirement of 32-bit and would have impact on database's utilization of memory, querying window size, cache, and storage. Edit: 32 bits worth of games played means about 4 billion games. 4 billion X 4 bytes for 32-bit = 16GB just for the 32-bit ID's. 64-bit ID's would need 32GB for the 4 billion games. I guess memory and storage weren't that cheap back then.

mikeash 9y ago
It sounds like it was client side, not server side. Most likely the iOS client was using Objective-C's NSInteger or Swift's Int, just because that's the default choice for most programmers working in that language, and they didn't think it through.
markcerqueira 9y ago
It also could've been just the person picking an int over a long. Is ints vs. longs the first place to look for optimizing efficiency/performance?
- cesarb 9y ago
  On a 32-bit system, a "long" is usually also 32 bits. On a non-Microsoft 64-bit system, a "long" is usually 64 bits. On both 32-bit and 64-bit systems (Microsoft or not), an "int" is usually 32 bits. If the issue happened only on 32-bit iPads, but not on 64-bit iPads, the programmer probably picked a "long", not an "int". Had the programmer picked an "int", the problem would also happen on 64-bit iPads.
  - e28eta 9y ago
    Our iOS app with Java backend was using long for database IDs on both ends. I was going through the ILP32->LP64 conversion process and when I realized we had a pretty serious discrepancy. I think it's a really easy mistake for the first developer to make (especially because they weren't a C/Obj-C programmer), and then the sort of thing that no one audits after that.
    - cesarb 9y ago
      Yeah, Java always uses 64 bits for "long", even on 32-bit systems. Which only adds to the confusion, since it's different from C and C++. (Another place where Java is confusingly different: "volatile" implies a memory barrier in Java, but not in C and C++.)

creepydata 9y ago

This is an fairly easy mistake to make for a novice developer to make. It even has a specific name - integer overflow - https://en.wikipedia.org/wiki/Integer_overflow https://en.wikipedia.org/wiki/Integer_overflow The original Pacman crashes at level 256 for the same reason. - http://pacman.wikia.com/wiki/Map_256_Glitch http://pacman.wikia.com/wiki/Map_256_Glitch

wvenable 9y ago

> Meaning, I'm not sure what the developer was thinking A 32bit integer is pretty much the default numeric type for the majority of programming tasks over the last 20 years. Even with 64bit CPUs, 32bit is still a common practice. Probably 99% of all programmers would make the same choice unless given specific requirements to support more than 2 billion values.

xapata 9y ago
> 99% of all programmers Many dynamically typed languages have an automatic change from int to bigint rather than allowing overflow. For example, Python.
- mort96 9y ago
  Others, like JS and Lua, just use doubles, meaning they'll never overflow - instead every 2 numbers start to be considered equal. Then a while after that every 4, etc. Not exactly optimal behavior when using incrementing IDs.
  - tripzilch 9y ago
    however, doubles represent integers accurately up to 53 bits. so that's still quite a lot before you run into that problem.
ewjordan 9y ago
It's often not even an explicit choice, it's just default behavior. Up until recently, Rails defaulted to 32 bit IDs, so there are a ton of apps out there that could have these issues, especially since Rails has always prided itself on providing sane defaults: https://github.com/rails/rails/pull/26266 https://github.com/rails/rails/pull/26266

sundvor 9y ago

As a consolation: Over 2 billion games played - congratulations!

qqg3 9y ago

I don't think you do understand, you sound like you're upset that a developer "set" this limit. When in reality it's tied to fundamental programming principles. It wasn't really a conscious decision to say, "I'm only going to account for 2bil games"...

mcv 9y ago

Probably when this was initially developed, nobody thought you'd ever go over 2 billion games. This error is brought to light by your success and popularity. Computer history is riddled with assumptions like that. The Y2K problem, Unix dates running out in 2037, and 32 bit computers unable to address more than 4 GB of memory are just the big ones. It's everywhere. Smaller software projects are generally built for what you need right now, and less for what might happen in the distant future. Ideally you want to retain some awareness that this is an issue so you can start working on once you go over a billion games, but in a small company, there are probably always more urgent things to worry about, and nobody ever gets around to fixing this technical debt.

obj-g 9y ago

> Meaning, I'm not sure what the developer was thinking, and at this point, I'm not going to track down exactly who it was and point fingers. As a developer, this sentence made my skin crawl.