Crash when starting level 1 #614
Comments
|
|
|
Just commenting out this->music_pointer::reset(music) at this line 77 stops the crash. But I'm not sure if that would be the fix. Sounds like that might leak memory. |
|
Please use triple backticks when pasting multi-line program output, so that Github does not mangle the text by treating it as Markdown. Yes, removing that would likely cause a memory leak. Also, since it is a call to a I start level 1 fairly often, and have not encountered a crash. What configuration is required to trigger this crash? What is the value of the pointer that it is attempting to free? |
|
As you can see in the later comments it's 0x0. But I tried an if (music) { this->music_pointer::reset(music); } and that still crashed. So perhaps the value was optimized out by gdb/compiler flags. My configuration is a standard Ubuntu 21.10 upgraded to today. I tried both dxx-rebirth_20211125-src.tar.xz and master. I did scons && scons install The .so files that seem relevant are at these ABI versions on Ubuntu (stack frames above these are in dcx:: namespace, so part of dxx-rebirth): |
I don't see that. I want the values of
That should have deferred the reset until later, and thus deferred the crash until later. It's possible that it did defer it, but not by enough for you to tell the difference without comparing stack traces.
That was not what I meant. If the problem is a bug in the game's code, it should be reproducible if I configure my game as you have configured yours. If the problem is in a supporting library, then matching your game configuration while using a different distribution might not reproduce it. So far, I have not been able to reproduce the crash on my system. Does Valgrind's memcheck show anything useful? A crash due to a mismatched free, or a free of an uninitialized variable, will usually be diagnosed by Valgrind. Game performance under Valgrind is slow, but for a crash this easily reached, that should not be a problem. |
|
Here are the valgrind logs. The screen gets flooded by a repeat of the same things: valgrind-out.txt From that valgrind output, when I do this, it also doesn't crash anymore. Maybe that Mix_Music is uninitialized when Mix_FreeMusic(m) is first called?: |
|
Your valgrind logs appear to be missing the early lines. It starts in the middle of a stack trace. However, there is enough to research this. This appears to be FluidSynth/fluidsynth#748 ( According to that issue, SDL2_Mixer deletes the fluidsynth objects in the wrong order, leading to a crash. Older versions of fluidsynth happened not to crash immediately, but as I read the discussion in the issue, the fluidsynth developers consider this an SDL2_Mixer problem. I am aware you are using SDL_Mixer. However, inspecting the source for SDL_Mixer (or your backtrace) shows that it also calls I cannot fix this problem in Rebirth, because this is not a bug in Rebirth. At best, I could add a hack to lock out your ability to use music when using fluidsynth, so that there would be no need to free music. However, as a fixed version of SDL2_Mixer is available, and the fix is simple, I am inclined to close this issue and refer you to the maintainer for your SDL_Mixer package. Please file a ticket with those maintainers, citing the fluidsynth issue and optionally this ticket. They should be able to backport the patch to apply to SDL_Mixer. It does not apply as-is due to text conflicts, but the change is conceptually simple. You may also be able to avoid the crash by using SDL2 instead of SDL1 for Rebirth, if your Ubuntu distribution has picked up the fixed version of SDL2_Mixer. Although I was not involved in the fluidsynth or SDL_Mixer work on this, I am available to answer questions if needed.
That change causes Rebirth never to free any Mix_Music objects. By leaking the object, you avoid calling the deletion code that crashes. |
|
This makes sense, so it's a fluidsynth issue and I'll just play with the memory leak and/or try with sdl2 until fluidsynth's fixed release arrives in my Ubuntu distribution. Thanks a lot for the explanation. For the next person: apt-get install libsdl2-mixer-dev ; scons d2x=sdl2 sdl2_sdl2=1 |
|
As described in that issue, it's not a fluidsynth issue. It's an SDL_mixer issue. The position of the fluidsynth project is that affected versions of SDL_mixer use fluidsynth in an invalid way. Their patch, that I linked above, changes SDL_mixer to use fluidsynth in a valid way. Since it is not a fluidsynth bug, I do not expect that a newer fluidsynth package your distribution will fix this. However, I expect that a new enough SDL_mixer or SDL2_mixer from your distribution would fix this. Even there, I wouldn't expect a newer version of SDL_mixer unless your distribution's maintainer is notified that a fix is needed. You can simplify that scons invocation to: Since this appears to be a problem in an external library, closing without change to Rebirth. You're welcome to continue discussion here if you have further questions. |
Awesome, thanks. For building DX1, I had success with |
The text was updated successfully, but these errors were encountered: