Beta 1703100617, malloc(): invalid size (unsorted), 'Wonderboy: The Dragons Trap' game fails to launch. #10317
Comments
|
Woops, I really did typo my own name in that email 😂 Will be back in my office tomorrow morning so I'll try to reproduce locally but it does sound like a recent Steam client change breaks Steamworks in some way. (At least it's not shm this time...) |
|
Possibly related: #8542 |
|
I wasn't able to reproduce this locally, but I'm testing on SteamOS and Fedora - since it's related to memory I wonder if Valgrind could catch it? Running this should make it work: It'll probably take forever to start but it should dump a bunch of stacks whenever the program does something wrong, the Steam side may not have the best symbols but it should at least confirm that libsteam_api is where the malloc assert gets hit. EDIT: Ran valgrind on my end and sure enough Steamworks has some nasty errors: Wouldn't be surprised if this crashed on the right system. |
|
Hello @984512547, I'm reminded of #10002 (comment) as a semi-recent example of libgtk3-nocsd misbehaving. |
|
If this is on a Wayland desktop, a possible alternative in Wonder Boy's case may be to update the bundled SDL to 2.28.5 and set SDL_VIDEODRIVER=wayland, which should go straight to SSD without GTK in the middle. |
|
Pushed a new beta branch on Steam called |
|
|
One possible fix for this would be to take the strdup here in realpath... https://github.com/bminor/glibc/blob/master/stdlib/canonicalize.c#L409 ... and inline it with a change to increase the size of the allocated buffer by 1, to account for the strcat attempt that Steamworks seems to be doing here. strdup.c just uses strlen + 1 for the buffer size, so changing it to be strlen + 2 with a Note of Shame explaining the inlined routine could be a change that the Steam Runtime does (and only SLR, no way is this getting upstreamed) to accommodate Steamworks versions from 2012-2017 which have this bug. It's either that or detect the affected .so files in every depot and swap them out with hotfixed versions behind everybody's back somehow, not sure which is worse! |
|
Sorry for all the double posting, but! Out of curiosity I took a look at musl and they just always allocate PATH_MAX, which seemed like overkill until I looked at the Linux man page for realpath:
The Open Group spec is unfortunately more vague:
I'm inclined to say the former is enough to make the call that standard strdup is not as good a fit for realpath as a specialized version that always does PATH_MAX to ensure that the buffer is always the right size no matter how the path is used afterward (in other words, if paths were their own data type, we would want to duplicate a path and not a generic string). This is at least slightly easier to justify having a patch for, though I still wouldn't want to be the one that tries to submit a change that increases memory use in most cases... |
|
Threw this together, pretty sure this has to be filed on glibc's Bugzilla first, but this at least does what I suggested yesterday: |
|
Guess that's a "no" until someone overrules it: https://sourceware.org/bugzilla/show_bug.cgi?id=31198 |
Your system information
tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]Please describe your issue in as much detail as possible:
@fibitijibibo
Steps for reproducing this issue:
The text was updated successfully, but these errors were encountered: