View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011564 | Dwarf Fortress | Technical -- General | public | 2020-06-21 10:24 | 2020-06-21 13:14 |
Reporter | Cheaterman | Assigned To | lethosor | ||
Priority | low | Severity | crash | Reproducibility | always |
Status | confirmed | Resolution | open | ||
Platform | Linux | OS | Gentoo | ||
Product Version | 0.47.04 | ||||
Summary | 0011564: Segfault when starting game, infinite loop when stopping it | ||||
Description | Two issues in one - first is segfault when starting game, because OpenAL error reporting is broken: In the file g_src/music_and_sound_openal.cpp L493, you'll notice a line like this: ALenum alGetError( void ) { _alGetError(); } Pretty weird, since the _alGetError() result should be returned. Fix it as follows: ALenum alGetError( void ) { return _alGetError(); } If you compile with -Werror=return-type you'll find another similar issue with alIsEnabled: ALboolean alIsEnabled( ALenum capability ) { _alIsEnabled(capability); } This one obviously also needs a return. Finally, the infinite loop when stopping is also because of a missing return in int enablerst::loop. Just add "return 0;" at the end. Fixing this infinite loop however will highlight YET ANOTHER segfault in musicsoundst::deinitsound(): alcMakeContextCurrent(NULL); It's invalid to give a NULL pointer as argument to alcMakeContextCurrent(). Just remove the call. With all of this done, the game finally works properly for me, I can start it and I can close it. Thanks in advance for fixing it. | ||||
Tags | binary patch, Probable Quick Fix | ||||
|
I confirmed that all of these issues are present in a stock 0.47.04 copy. I'm not sure why the third one would cause an infinite loop, though - the only call to `enabler.loop()` is at the end of `main()`, as follows:int result = enabler.loop(cmdLine); SDL_Quit(); #ifdef WIN32 timeEndPeriod(ms); #endif return result; Perhaps a compiler optimization is to blame here. (I'm attaching the "binary patch" label since that's historically what we've used for issues where code changes are available, even though the patches you've suggested aren't binary patches.) |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-06-21 10:24 | Cheaterman | New Issue | |
2020-06-21 13:14 | lethosor | Note Added: 0040595 | |
2020-06-21 13:14 | lethosor | Tag Attached: binary patch | |
2020-06-21 13:14 | lethosor | Tag Attached: Probable Quick Fix | |
2020-06-21 13:14 | lethosor | Assigned To | => lethosor |
2020-06-21 13:14 | lethosor | Status | new => confirmed |
2022-05-02 19:25 | lethosor | Relationship added | has duplicate 0011866 |