[HN Gopher] Investigating why Steam started picking a random font
___________________________________________________________________
Investigating why Steam started picking a random font
Author : rbanffy
Score : 308 points
Date : 2022-11-19 19:12 UTC (3 hours ago)
(HTM) web link (blog.pkh.me)
(TXT) w3m dump (blog.pkh.me)
| develatio wrote:
| > 2038 is going to be a lot of fun
|
| Indeed it will be!
| kevin_thibedeau wrote:
| NTP epoch in 2036 is going to be better since it isn't getting
| any attention and there's going to be no shortage of broken IoT
| devices that fail.
| gary_0 wrote:
| We're gonna party like it's 1999!
| deathanatos wrote:
| Actually, we'll probably be partying like it's Fri Dec 13
| 1901 20:45:52 GMT.
|
| Ooh, Friday the 13th too, ominous.
| CodesInChaos wrote:
| At least we won't have to suffer though the 2106 problem.
| hoosieree wrote:
| Oh jeez, it's going to be so much worse than y2k.
| TillE wrote:
| Is Linux really not commonly using 64-bit file times yet? I know
| there are some years left, but it seems like a relatively
| straightforward problem that needs to be solved for everyone.
| cesarb wrote:
| > Is Linux really not commonly using 64-bit file times yet?
|
| It is, and that was the problem. The legacy 32-bit API the
| library loaded within Steam was using, or more precisely, the
| legacy 32-bit system call used by that library, could not
| represent the 64-bit time, so the kernel returned the EOVERFLOW
| (Value too large for defined data type) error. The root cause
| of the problem seems to be that Steam is still a 32-bit
| application (and hasn't been recompiled to used the Latest and
| Greatest version of glibc, which allows for 64-bit timestamps
| even on 32-bit processes).
|
| If his Linux installation did not use 64-bit file times, the
| timestamp stored for the file would have fit in 32 bits, and
| the error wouldn't have happened (though other things would
| probably have broken first).
|
| (Well, actually, Linux is using 34-bit file times, at least on
| ext4 and xfs, but that's a bit of a nitpicking: what matters is
| that it doesn't fit in 32 bits.)
|
| Edit: it seems that it's actually glibc that's returning the
| error, not the kernel, see
| https://news.ycombinator.com/item?id=33675526
| yyyk wrote:
| Steam client fonts are a mess even without y2038 bugs. There's no
| good way to change size globally - despite the entire client
| being based on HTML/CSS tech! The current 'solution'* is to edit
| stylesheets manually as if it were a new skin, and find/modify
| every invocation of font-size.
|
| * Or use Big Picture mode, which has other issues.
| shadowgovt wrote:
| (me before opening the link) "... on Linux."
|
| _click_
|
| "Hm, yes."
| the_af wrote:
| This is a corner case which could have just as well occurred on
| Windows (or a similar kind of bug), though. It's not the
| expected usage.
| shadowgovt wrote:
| The 2038 bug is definitely expected, and unlike in Linux,
| with its highly distributed and composable architecture,
| management of fonts on Windows is a responsibility of the
| monolithic operating system maintained by one company.
|
| It's not out of the realm of possibility, but I'd be a little
| startled if Windows hasn't already been gone over with a fine
| tooth comb for Y-2038 issues.
| lazide wrote:
| Considering how many crazy bugs are getting introduced now
| in windows, I wouldn't be that surprised.
| taeric wrote:
| Pretty sure one of the things they did in windows land was
| to just stop supporting 32 bit software.
| asddubs wrote:
| but windows still supports 32 bit executables, I'm pretty
| sure?
| taeric wrote:
| You could probably guess I don't claim to be
| authoritative here. :D I just recall there was a story
| not long ago about them doing some hard decisions going
| into 64 bit. https://learn.microsoft.com/en-
| us/troubleshoot/windows-serve... seems to indicate that
| you should mostly expect it to work.
|
| Odds are high I just saw the headlines about how they are
| stopping 32 bit sales of their OS. Though, I couldn't
| tell you for sure what I was misremembering.
| userbinator wrote:
| Windows' native API for dates consists of the types FILETIME
| and SYSTEMTIME which will handle 5-digit years, and even the
| old MS-DOS FAT timestamp goes up to 2107. The 2038 problem
| came from Unix and applications which use 32-bit Unix epoch
| time.
| naikrovek wrote:
| appleflaxen wrote:
| What an amazing anecdote. 2038 will likely be very crazy.
| nyanpasu64 wrote:
| Similarly I had a bug where KDE's zip unpacker would extract
| empty(?) folders but interpret uninitialized memory as the folder
| date, creating folders with a modification time after 2038 that
| Wine couldn't open.
| dylan604 wrote:
| We had a computer dedicated to encoding video that had a
| misconfigured date that was in the future so all of the encodes
| from it had the incorrect date. It played havoc with another
| program on a different system with the correct date. It took a
| few days for that program's support team to recognize the
| issue. There was nothing wrong with the file as in the
| video/audio data was not corrupt or anything. Doing a stream
| copy to a new file with a sane date made the program happy
| again.
|
| Never did understand why the software even looked at dates, and
| support couldn't explain it either.
| hoppla wrote:
| When i first learned of the 2038 problem, i changed the date on
| my computer and watched it tick up to 2^32. All sorts of things
| crashed, most notably, the Norton antivirus software. This was on
| a windows XP if I recall correctly
| Twirrim wrote:
| Shades of the fun yet to come, I guess. I don't _see_ any issue
| against it in their repo?
| https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issue...,
| but trying to search for that can be tricky.
| wentin wrote:
| This is catching a bug early. Eventually this will happen to all
| gamers of steam when the year 2038 comes. Hopefully developers
| can fix it before then
| joosters wrote:
| It seems odd that the problem is in the _access_ time of the
| files - why does a font library (or, almost _any_ program) care
| about the last read time of a file? Sure, the modification time
| is important, but it 's pretty rare that code should care about
| when a file has been read before. The only program I have heard
| of that broke when access times are unreliable was mutt, the
| email client.
| cesarb wrote:
| > why does a font library (or, almost any program) care about
| the last read time of a file? Sure, the modification time is
| important, but it's pretty rare that code should care about
| when a file has been read before.
|
| There's no separate system call for the modification time; a
| single system call (https://man7.org/linux/man-
| pages/man2/stat.2.html) returns the three times (atime, mtime,
| ctime) together. The font library probably wanted just the
| modification time (to check whether the font cache is stale),
| but it cannot get the mtime without also getting the atime (and
| ctime).
| joosters wrote:
| Sure, but EOVERFLOW isn't coming from stat() in this case, is
| it? The man page states that this is returned for problems
| with file _sizes_ too big for 32 bits, not for struct
| timespecs. Something else must be doing things with the
| atime, I would guess?
| quietbritishjim wrote:
| I think stat() in the 32bit version of libc is making the
| 64 bit system call to get the value from the kernel and
| noticing that it would overflow. The man page for stat()
| [1] says that EOVERFLOW is a possible error value so that
| lines up.
|
| [1] https://man7.org/linux/man-pages/man2/lstat.2.html
| cesarb wrote:
| > I think stat() in the 32bit version of libc is making
| the 64 bit system call to get the value from the kernel
| and noticing that it would overflow.
|
| I'm not certain I'm looking at the correct file, but that
| does seem to be the case, at least on latest glibc: stat
| redirects to fstatat(AT_FDCWD) (https://sourceware.org/gi
| t/?p=glibc.git;a=blob;f=sysdeps/uni...), and fstatat
| calls a 64-bit system call and fails with EOVERFLOW if
| any of st_ino, st_size, st_blocks, st_atim, st_mtim,
| st_ctim wouldn't fit in the 32-bit struct (https://source
| ware.org/git/?p=glibc.git;a=blob;f=sysdeps/uni...).
|
| Yes, st_ino too, which means it could also break on a
| filesystem with large enough inode numbers. Using a
| 32-bit userspace nowadays seems more problematic the more
| I look.
| userbinator wrote:
| In this case, just letting it roll over to the 70s
| would've probably not created this bug.
| joosters wrote:
| Yes, I read that man page. It states:
| EOVERFLOW: pathname or fd refers to a file whose size,
| inode number, or number of blocks cannot be represented
| in, respectively, the types off_t, ino_t, or blkcnt_t.
| This error can occur when, for example, an application
| compiled on a 32-bit platform without
| D_FILE_OFFSET_BITS=64 calls stat() on a file whose size
| exceeds (1<<31)-1 bytes.
|
| None of off_t, ino_t or blkcnt_t are to do with times,
| they are related to file size. The man page has nothing
| to say about EOVERFLOW and times. Perhaps the man page is
| out of date, or perhaps it is another syscall that is
| returning EOVERFLOW?
|
| I'd be surprised if it was actual userspace code in the
| font library that was generating that errno. After all,
| if you care enough to spot an overflow in your
| calculations, you probably care enough to handle that
| error case better (and know enough about the situation to
| handle it properly). Something must be making a specific
| syscall, getting EOVERFLOW, then throwing it back up to
| the user. But is it really the ubiquitous stat() ?
| [deleted]
| phshift wrote:
| Note: The linux manpages cover the syscall interface of
| the linux kernel, not the glibc implementation. You can
| check the glibc source code yourself, but glibc will set
| errno for multiple reasons outside of the raw syscall,
| including for time overflows.
| cesarb wrote:
| > Note: The linux manpages cover the syscall interface of
| the linux kernel, not the glibc implementation.
|
| They cover both, but they focus more on the glibc
| wrappers. For instance, the manpage for stat(2) we're
| talking about says "On success, zero is returned. On
| error, -1 is returned, and errno is set to indicate the
| error.", which is not the syscall interface return value
| (the syscall does not know about errno, it returns the
| negative of what will end up in errno instead of -1).
| Another example is the manpage for exit(2), about the
| _exit() function (the exit() function, without the
| underscore, is at exit(3) since it's not a system call),
| which says "In glibc up to version 2.3, the _exit()
| wrapper function invoked the kernel system call of the
| same name. Since glibc 2.3, the wrapper function invokes
| exit_group(2), in order to terminate of the threads in a
| process."
| ericyd wrote:
| CaliforniaKarl wrote:
| Holy heck I love that. Try to cheese a Stanley Parable
| achievement, and one dependency deep down inside Steam breaks.
| damiante wrote:
| I have a similar issue with Caprine, the desktop frontend for
| Facebook Messenger. I have not however messed with my datetime
| settings, not is it such a big issue that I have taken the time
| to try to fix it (I don't use Messenger often and on desktop even
| less).
| nickphx wrote:
| I've used https://github.com/gibbed/SteamAchievementManager. To
| unlock game achievements on steam.
| notafraudster wrote:
| Cheating to get the Stanley Parable achievement devalues the hard
| work that all the rest of us did to earn it.
| mrighele wrote:
| On the other side this post reminded me that is has been
| several years since I last played it, so I will check if I am
| eligible for the achievement.
| labster wrote:
| Username checks out.
| js8 wrote:
| Better play it today, because after 2028, you're never getting
| the achievement.
| WJW wrote:
| Unless steam updates their font dependencies somewhere in the
| upcoming 16 years, of course?
| [deleted]
| thesnide wrote:
| Nice.
|
| Spoiler ahead: But I'd use faketime in userspace to avoid messing
| up the system ;)
| M4v3R wrote:
| 2038 is going to be an interesting year that's for sure. I'm big
| into Final Fantasy VII modding/speedrunning and while reverse
| engineering the game I stumbled upon some code that actually
| checks if the current date is before 2038. If it's not it refuses
| to run. I have no idea why they put this kind of check in the
| game's code, I tried to remove it but the game actually still
| didn't start so there is probably some issue that prevents it
| from working when the date overflows.
|
| I can only imagine that a lot of other legacy software will have
| similar issues when we reach year 2038.
| MrLeap wrote:
| Is this in the ps1 version, the pc port, or are we talking the
| remake or something else?
| cesarb wrote:
| > I stumbled upon some code that actually checks if the current
| date is before 2038. If it's not it refuses to run. I have no
| idea why they put this kind of check in the game's code,
|
| That's actually very clever. Instead of crashing in unexpected
| ways or doing odd things, just cleanly exit. If you really want
| it to run after 2038, you have to emulate the clock, which
| would then avoid these potential Y2038 bugs.
| Scalene2 wrote:
| Quick question, do most OSes need admin/root/whatever perms to
| change the system time? If not, I wonder if there are any
| potential serious exploits that could take advantage of this
| ability.
| johnchristopher wrote:
| A long time ago, I was playing Far Cry. Console was opened. Then
| all of a sudden IRC chat messages from the IRC client I was
| running in the background would appear in-game, with fronts and
| effects (shadows) from the game. _shrugs_
| cpeterso wrote:
| Sounds like a graphics driver bug, as if it was reusing some
| GPU textures in both applications.
| MichaelZuo wrote:
| Maybe no one understands how computers really work.
| kevin_thibedeau wrote:
| They're magic. The question is will we become Asgardians or
| Eloi.
___________________________________________________________________
(page generated 2022-11-19 23:00 UTC)