Closed musuruan closed 1 year ago
Can you do me a favor? Run tuxmath with the environment variable SDL12COMPAT_DEBUG_LOGGING=1 set.
It'll print something like this out at startup:
INFO: sdl12-compat 1.2.61, built on May 16 2023 at 14:30:00, talking to SDL2 2.27.0
Can you tell me what your computer prints there?
Because I'm not crashing (and valgrind isn't reporting anything that looks like a double-free error), but it is saying this:
Error: I couldn't load a sound file:
/usr/share/tuxmath/sounds/buzz.wav
The Simple DirectMedia error that occured was:
Invalid block alignment
And I'm wondering if this is the difference between crashing and not crashing right here.
Actually, nevermind, I can see all the version numbers in that stack trace, which is pretty nice! :)
And I'm wondering if this is the difference between crashing and not crashing right here.
Also, this is definitely the difference, since the for-loop exits if it hits this condition. Let me mess with this more on my end.
(First off, wow, I installed Fedora 38 in a virtual machine and "yum install tuxmath" and just for a goof I ran it under gdb...I really did not expect the system to download debug symbols for everything, and as I stepped through the code, download individual source files for various libraries on the fly for viewing. I don't know if this is a Fedora thing or a general newer Linux thing, but that was amazing.)
So here is where this is exploding, in SDL_mixer's mixer.c:
616 if ( !loaded ) {
617 SDL_free(chunk);
618 if ( freesrc ) {
619 SDL_RWclose(src);
620 }
621 return(NULL);
622 }
623
Item 4 in the previously-mentioned for-loop fails to load for whatever reason (probably because it reports its block alignment as zero and SDL2 doesn't like that...we should maybe just force the alignment to 1 in these cases?). Fail or not, SDL_LoadWAV_RW, which SDL_mixer calls to load the .wav file, will call SDL_RWclose(src).
But only when failing, as item 4 does, does SDL_mixer also try to call SDL_RWclose, causing a double-free.
The problem is this: that code was fixed in SDL_mixer...12 years ago.
https://github.com/libsdl-org/SDL_mixer/commit/23b6289224edb24fcb8266fce9647822b69c4298
But since this is on the SDL-1.2 branch, it has never had a formal release, so it's not in the ancient SDL_mixer 1.2.12 that distros ship because it was the final official release before we moved to SDL2-only releases.
So this is not an sdl12-compat bug, and you may hit the same crash if you used classic SDL 1.2 in this scenario. I didn't hit it on my system originally because I built SDL_mixer from the latest source code for the SDL-1.2 branch on GitHub.
The most expedient course for Fedora would be to add that specific commit as a custom patch in the SDL_mixer 1.2 package, since it's a generally good, small fix and it specifically would fix the currently-broken tuxmath package.
As a secondary option, I'm going to look into why that .wav file is failing to load, and if we apply a fix to SDL2, then when Fedora picks up the upcoming 2.28.0 release, sdl12-compat will use it and this won't have a chance to double-free because the .wav won't fail to load. But this is not a good primary solution because all you need is one of those .wav files to get a little corrupted on the filesystem and fail to load, and you'll still crash, unless the SDL_mixer patch is applied, too.
(CC @Conan-Kudo, in case he finds this to be interesting information.)
(First off, wow, I installed Fedora 38 in a virtual machine and "yum install tuxmath" and just for a goof I ran it under gdb...I really did not expect the system to download debug symbols for everything, and as I stepped through the code, download individual source files for various libraries on the fly for viewing. I don't know if this is a Fedora thing or a general newer Linux thing, but that was amazing.)
This is something that has been available since Fedora Linux 35. Since Fedora Linux 38, you can do performance analysis using perf
of everything built in the distribution.
So here is where this is exploding, in SDL_mixer's mixer.c:
616 if ( !loaded ) { 617 SDL_free(chunk); 618 if ( freesrc ) { 619 SDL_RWclose(src); 620 } 621 return(NULL); 622 } 623
Item 4 in the previously-mentioned for-loop fails to load for whatever reason (probably because it reports its block alignment as zero and SDL2 doesn't like that...we should maybe just force the alignment to 1 in these cases?). Fail or not, SDL_LoadWAV_RW, which SDL_mixer calls to load the .wav file, will call SDL_RWclose(src).
But only when failing, as item 4 does, does SDL_mixer also try to call SDL_RWclose, causing a double-free.
Thank you very very much for this!
The most expedient course for Fedora would be to add that specific commit as a custom patch in the SDL_mixer 1.2 package, since it's a generally good, small fix and it specifically would fix the currently-broken tuxmath package.
Neal (thanks!) has already updated and reassigned the original downstream bug report and new packages are coming to updates-testing.
Thanks again!
(Thanks everyone; Fedora's team is on top of things, as usual, and I'm always grateful for it!)
As a quick followup, the SDL2 fix I mentioned is now in revision control and will be in the 2.28.0 release that we're currently working to finish up: https://github.com/libsdl-org/SDL/issues/7714
But again, the SDL_mixer patch that already made its way into Fedora is still the most correct fix here, so no further action is required.
Fedora introduced sdl12-compat in F35. Since then tuxmath segfaults at startup. It might be a problem in sdl12-compat.
Relevant downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2031642
I am currently on F37 with sdl12-compat v1.2.60-1.fc37 installed from RPM.
I made a bit of debugging and it seems it crashes here when i=4: https://github.com/tux4kids/tuxmath/blob/upstream/2.0.3/src/fileops_media.c#L271
Backtrace:
If you disable sound by running tuxmath with the
--nosound
option, it runs fine because this section is avoided.Can you please have a look?
Thanks!