Portal 2 crashes if you have 128 cores, due to 15 year old assumptions

Portal 2 crashes if you have 128 cores, due to 15 year old assumptions(twitter.com)

63 points by notpopcorn 4 years ago | 11 comments

notpopcorn 4 years ago |

MAX_THREAD_IDS is defined as 128 in a file with a copyright notice of 2005, which was when the very first consumer dual core processors started getting released:

https://github.com/perilouswithadollarsign/cstrike15_src/blo...

Entirely reasonable that no one in 2005 would even consider the possibility of 128 core processors. I bet nobody reconsidered or even looked at that code ever since, until it started breaking because of today's extremely parallel cpus starting to get somewhat affordable for consumers.

donkarma 4 years ago | |

it's weird because they used to use regular TLS variables and then they swapped to this at some point, pretty sure TF2 uses regular ones

perihelions 4 years ago |

>"The solution?"

    # echo 0 > /sys/devices/system/cpu/cpu{121..127}/online

>"Disabling just one core makes the game start, but then it segfaults when the menu opens. Disabling six cores makes the menu work. Disabling seven makes the rest of the game work too."

What path do you walk to be able to figure out this kind of black magic by yourself?

notpopcorn 4 years ago | |

It's just like the end of Portal 1: you have to remove some cores in order to win the game. ;)

bravetraveler 4 years ago | |

For anyone curious/hopeful, this only really disables the cores in terms of the kernel.

They're still consuming about the same power they would normally (when idle) :)

Edit: cpusets would probably handle this better dynamically. I'm not sure if that influences the count visible to a process

Davidbrcz 4 years ago | |

This isn't really black magic.

Just reading a book on the Linux kernel and it's structure should be enough to get you going.

laserbeam 4 years ago |

To be fair, the issue is not that there are too many physical cores, or that someone set that constant to 128. The issue is the code that spawns 1 thread per core doesn't check that constant to limit how many threads it spawns.

tinus_hn 4 years ago | |

One would wonder what this game is planning to do with 128 threads running simultaneously.

laserbeam 4 years ago | | |

Does it matter? The 128 assumption for these kind of things is there just to allocate a fixed array of 128 thread ids, and going outside that array is a out of bounds magic with pointers.

It's totally reasonable to have a limit. It's totally reasonable to make that limit way higher than you'd think you'd ever need. It's only a bug if you don't enforce thay limit and fail to check for it. And, it's really easy to forget to do that when the easiest way to verify thesr bugs is "wait 15 years until hardware improves".

krallja 4 years ago |

I’m not super familiar with cgroups, but I have to assume there’s a parameter for limiting the number of cores available to a process, rather than doing it at the kernel level in /sys