|Anonymous | Login | Signup for a new account||2020-07-09 18:01 UTC|
|My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003766||Zandronum||[All Projects] Bug||public||2020-02-21 08:30||2020-05-17 20:26|
|Status||closed||Resolution||no change required|
|Platform||Linux||OS||Arch Linux||OS Version||5.5.4-arch1-1|
|Target Version||Fixed in Version|
|Summary||0003766: Crash on Launch|
|Description||This was the only verbose from the terminal. I've done a fresh install and the issue still persists. This has happened as of yesterday.|
free(): double free detected in tcache 2
Aborted (core dumped)
|Steps To Reproduce||Launch Zandronum on Arch Linux|
|Issue is present in both 3.0 and 3.1 180901-1533|
Torr Samaho (administrator)
|Can you compile in debug mode and see if it still crashes? If so, can you post a backtrace of the crash?|
|Yes, Give me a bit.|
Starting program: /home/blushberry/zandronum_build/zandronum/buildclient/zandronum -iwad ~/.iwad/doom2.wad
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff4fdd700 (LWP 105381)]
Thread 1 "zandronum" received signal SIGSEGV, Segmentation fault.
0x00007ffff61b4f1e in malloc () from /usr/lib/libc.so.6
#0 0x00007ffff61b4f1e in malloc () at /usr/lib/libc.so.6
#1 0x00007ffff6a2ede5 in FMOD::MemPool::alloc(int, char const*, int, unsigned int, bool) () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000002 0x00007ffff6a52d41 in FMOD::OutputALSA::addALSADriver(char const*) () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000003 0x00007ffff6a52f8d in FMOD::OutputALSA::getALSANameHintDrivers() () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000004 0x00007ffff6a5356d in FMOD::OutputALSA::enumerate() () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000005 0x00007ffff6a53915 in FMOD::OutputALSA::getNumDrivers(int*) () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000006 0x00007ffff6a43e6e in FMOD::SystemI::getNumDrivers(int*) () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000007 0x00007ffff6a40cf3 in FMOD::System::getNumDrivers(int*) () at /home/blushberry/zandronum_build/zandronum/fmodapi42416linux64/api/lib/libfmodex64-4.24.16.so
0000008 0x0000555555ca8633 in FMODSoundRenderer::Init() (this=0x555557a9c7c0) at /home/blushberry/zandronum_build/zandronum/src/sound/fmodsound.cpp:846
0000009 0x0000555555ca819b in FMODSoundRenderer::FMODSoundRenderer() (this=0x555557a9c7c0) at /home/blushberry/zandronum_build/zandronum/src/sound/fmodsound.cpp:622
0000010 0x0000555555cafde0 in I_InitSound() () at /home/blushberry/zandronum_build/zandronum/src/sound/i_sound.cpp:266
0000011 0x0000555555813699 in I_Init() () at /home/blushberry/zandronum_build/zandronum/src/sdl/i_system.cpp:349
0000012 0x000055555589fa4f in D_DoomMain() () at /home/blushberry/zandronum_build/zandronum/src/d_main.cpp:2912
0000013 0x0000555555812f4e in main(int, char**) (argc=3, argv=0x7fffffffe648) at /home/blushberry/zandronum_build/zandronum/src/sdl/i_main.cpp:380
Here is some additional information if needed
edited on: 2020-02-27 23:39
I figured out what went wrong, FMODEx 4.24.16 on arch linux causes a memory leak so an upgrade of FMODEx is needed.
I also run Arch, and I'm seeing this issue. It's rendered Zandronum unplayable. :(
Zandronum broke immediately after I did a system upgrade. That's not to suggest that doomjoshuaboy's analysis is wrong here: an upgraded library can absolutely trigger bugs in other code that were latent by pure chance before the upgrade. However, it seems some recent upgrades in Arch broke a *lot* of games — more than just Zandronum, including many Unity games.
There's some discussion on the Arch BBS:
Topic A:https://bbs.archlinux.org/viewtopic.php?id=253210 [^]
Topic B:https://bbs.archlinux.org/viewtopic.php?pid=1889747#p1889747 [^]
Topic B links to a GitHub issue against alsa-lib:https://github.com/alsa-project/alsa-lib/issues/27 [^] — my reading of it, and in particular, of this comment:https://github.com/alsa-project/alsa-lib/issues/27#issuecomment-593152336 [^] and the commit just prior to it, suggest that there might have been a legitimate bug that is either responsible or at least the trigger.
Topic B on the BBS also contained this gem:
> Downgrading alsa-lib (and alsa-utils) to version 126.96.36.199-3 (and 1.2.1-2 respectively) solved the issue.
*Which worked for me!* (Though I can't keep those downgraded forever; however, hopefully a subsequent release of alsa-libs will contain the fix in the bug, and hopefully that version will work, removing the need for downgrading.) Both of those were upgraded on 20 Feb.
The downgrade commands are:
sudo pacman -Uhttps://archive.archlinux.org/packages/a/alsa-lib/alsa-lib-188.8.131.52-3-x86_64.pkg.tar.zst [^]
sudo pacman -Uhttps://archive.archlinux.org/packages/a/alsa-utils/alsa-utils-1.2.1-2-x86_64.pkg.tar.zst [^]
(N.b. your next normal full upgrade will undo this. Which is good, once fixes come out.)
So, that gets me back into being knee-deep in the dead for the moment. Again, it isn't 100% clear to me if this is a straight-up bug in alsa-lib, or if it triggers bad memory management in other libraries, or some mix of both — I don't mean to contradict any plans to push other fixes. But I thought I'd link in the other posts/topics, since they seem to be helpful.
edited on: 2020-03-03 14:43
I can confirm with both Josh's and Thanatos' posts that these both do fix the issue. It's probably better to go with Thanatos' fix until the library itself has been fixed.
As of recent 3.1 builds, Zandronum is compiled with FMOD 4.44.64 which no longer exhibits this issue.
A workaround for 3.0 is to start with -nosound and set output type to SDL, then restart the game normally.
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
|Supporters:||Polygon EpicTyphlosion thanatos mifu|
|Opponents:||No one explicitly opposes this issue yet.|
|2020-02-21 08:30||Polygon||New Issue|
|2020-02-21 08:40||Polygon||Note Added: 0021215|
|2020-02-23 20:09||Torr Samaho||Note Added: 0021216|
|2020-02-23 21:29||Polygon||Note Added: 0021217|
|2020-02-23 22:20||Polygon||Note Added: 0021218|
|2020-02-23 22:46||Polygon||Note Edited: 0021218||View Revisions|
|2020-02-23 22:48||Polygon||Note Added: 0021219|
|2020-02-24 00:42||Polygon||Note Deleted: 0021218|
|2020-02-24 20:32||Polygon||Note Added: 0021220|
|2020-02-27 23:36||doomjoshuaboy||Note Added: 0021222|
|2020-02-27 23:39||doomjoshuaboy||Note Edited: 0021222||View Revisions|
|2020-03-03 05:03||thanatos||Note Added: 0021223|
|2020-03-03 14:35||Polygon||Note Added: 0021224|
|2020-03-03 14:43||Polygon||Note Edited: 0021224||View Revisions|
|2020-05-17 20:18||AOSP||Note Added: 0021337|
|2020-05-17 20:26||Edward-san||Status||new => closed|
|2020-05-17 20:26||Edward-san||Resolution||open => no change required|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2020 MantisBT Team|