Chess.com Has Stopped Working On 32bit iPads After the Site Hit 2^31 Game Sessions (chess.com)

Apple's decision to go all in on 64bit-capable devices, OS and apps has caused some trouble for Chess.com, a popular online website where people go to play chess. Users with a 32bit iPad are unable to play games on the website, according to numerous complaints posted over the weekend and on Monday. Erik, the CEO of Chess.com said in a statement, "Thanks for noticing. Obviously this is embarrassing and I'm sorry about it. As a non-developer I can't really explain how or why this happened, but I can say that we do our best and are sorry when that falls short." Hours later, he had an explanation: The reason that some iOS devices are unable to connect to live chess games is because of a limit in 32bit devices which cannot handle gameIDs above 2,147,483,647. So, literally, once we hit more than 2 billion games, older iOS devices fail to interpret that number! This was obviously an unforeseen bug that was nearly impossible to anticipate and we apologize for the frustration. We are currently working on a fix and should have it resolved within 48 hours.

Comments

nearly impossible to anticipate?

[Eunuchswear]

This was obviously an unforeseen bug that was nearly impossible to anticipate

Only if you're an idiot.

Re:nearly impossible to anticipate?

[xxxJonBoyxxx]

The website has a "CEO", so yes, I can confirm.

Re:nearly impossible to anticipate?

[pz]

Two BILLION chess games?

I'd have not anticipated that a chess site would become that popular. Yes, it's easy to say that it's an obvious bug, but one has to select a variable size during development. Not everything can be stored in a 64 or 128-bit integer, because that would mean a lot of wasted space. So, would YOU have thought it reasonable to use an unsigned 32-bit integer for the number of chess games? I bet many developers would have.

The real problem, though, is no one remembered about that choice once the number of chess games crossed some really obvious threshold, like 1 billion. THAT event should have triggered some developer to think, "holy cow, can we even handle that many? What's the limit? Are we in danger of a Y2K problem?"

But chess games? Two BILLION of them? I'd have thought that would be plenty. Color me very pleasantly surprised.

Re:nearly impossible to anticipate?

[Nutria]

Both of those very common activities are extreme dangers of software development.

Because people who have learned the lessons are continuously pushed out to make room for the latest know-it-all hotshots with their hip Comp Sci languages.

Apple's fault?

[Anonymous Coward]

I'm not Apple apologist, but come on why point the finger at Apple? This would have happened on any 32-bit architecture. Blame the devs of the game for not knowing how this works, not Apple.

"32bit device cant handle IDs above 2,147,483,647"

[JoeyRox]

That's like saying 8-bit processors can't handle (signed) numbers above 128. The processors handle them fine. The programmers on the other hand...

Re:Obligatory Answer

[D.McG.]

And to the Slashdot editors, don't even try to blame this on Apple's decision to go with 64-bit CPUs. That decision is the only reason it's NOT broken on newer devices; since the apps are compiled natively for both 32-bit and 64-bit. Otherwise ALL devices would have rolled over at 2^31.

Re:Obligatory Answer

[D.McG.]

"Apple's decision ... has caused some problems" is quite a conclusion to jump to when ignorant of the facts. If one doesn't know what they're talking about, don't make such a claim.

Re:All of that for -1

[Tranzistors]

It is generally a good idea to store quantities in signed variables, because unsigned numbers overflow into valid numbers, which are less obvious bugs. If you have a game #-2147483648, cause of the bug is clear even to a novice. If an application starts to serve games that are really old even if you asked for the new ones, who knows why? Also, using unsigned numbers will not help much with saving memory space. If the game count reached 2^31, how long until it reaches 2^32?

Re:Obligatory Answer

[Solandri]

If they're using the same code base for their 32-bit vs 64-bit versions, the int declaration for session ID should be the same on both versions. 32-bit processors can handle 64-bit integers just fine. They just need two clock cycles to manipulate them instead of one. So if they took the same code and compiled it twice (once as 32-bit, once as 64-bit), the same bug should have shown up in the 64-bit version.

• They're using a different codebase for their 32-bit vs 64-bit versions, and it just so happened the 32-bit version had a bug the 64-bit version did not. It could easily have been the other way around.
• Or they use the same codebase and there's a bug present in both versions. It just turned into a fatal overflow error on the 32-bit version, while the 64-bit version could continue. (Possible since a 32-bit int compiled for 64-bit would have a bunch of zeroes added as padding - though whether it protects from overflow depends on the endian-ness of the processor).
• Or there's more going on here, and they're doing some other manipulation of Session ID further down in the code which is causing a crash on the 32-bit version, while the 64-bit version continues to run. (This could explain why the error happens at 2^31 instead of 2^32, even if Session ID were an unsigned long int.)

So it's not necessarily true that Apple's move to 64-bit is why it runs fine in the 64-bit version. I think the swipe at Apple is because they removed 32-bit apps from the App Store. Even if chess.com had found and patched this bug ahead of time (which they may have since the CEO has admitted he's clueless about this tech stuff), as I understand it owners of 32-bit iOS devices would've had to update their software by downloading the patch directly from chess.com. No auto-update via the App Store anymore for 32-bit apps.

Re:Obligatory Answer

[D.McG.]

I guarantee you that it's the same source code that just declares the variable as a "long" which is 4 bytes when compiled for 32-bit devices and 8 bytes when compiled for 64-bit devices. They should have used "uint64_t" which would have taken away the ambiguity and worked everywhere. It's as simple as that.
https://developer.apple.com/li...

Re:Chess.com

[BronsCon]

This website started in 2005, so unless they saw Nokia brick phones as the way of the future, I really doubt they thought they'd get anywhere close to that many games.

You mean to say they expected to fail before 2 billion games had been played?

Matter of fact, you can blame all (32 and 64) smart phones for this because no one ever seems to close out of their apps.

Why? Does the app continuously play games by itself if you leave it open, thereby artificially inflating the number of games played? No, I don't think it does. And we're talking about the number of games played, ever, not the number of games currently being played, or the number of app instances currently open. Whether people close out their apps or not has absolutely nothing to do with this.

The popular consensus is that most of chess playing traffic comes from old-school Linux users anyway.

Right. So are you saying that their games don't count toward the total number of games played? Because that's what got pushed over 2 billion.

They could just have games close and delete automatically after a period of time.

They could, sure. But, unless they want to deal with data integrity issues, the IDs would continue growing, and it's the ID being too high that is causing the problem. Well, I misspoke there, it's too small of an INT type being used that caused the problem, but that INT is storing the game ID, so it was the ID being too high that revealed the problem.

And, two billion people are never going to be on Chess.com at the same time.

Of course not, but two billion games will eventually have been played, as evident by the fact that this has happened.

But let's say they are, then just use multiple servers.

And the same number of games would have been played, still.

Don't blame the bits for this because the main audience is upgrading anytime soon.

I don't think anybody (except the developer) did this, actually. The fault lies squarely with the developer who used an architecture-dependent INT type rather than forcing a 64-bit INT.

Just keep showing me how much you don't know about things, Hayden. Oh, and good luck in August; let me know if you need a ride.