Vanilla-Conquer
Vanilla-Conquer copied to clipboard
Segmentation fault on mac build using RA demo
I got this project building on my mac and was able to start the maps off of the RA demo. but after I kill a couple buildings, it segfualts
I copied everything over from the directory so my build/vanillara.app/Contents/MacOS
looks like
MAIN.MIX RANOTES.ICO README.WRI REDALERT.INI REDALERT.MIX RESLIB.DLL THIPX16.DLL THIPX32.DLL snow_vtx.pal temp_vtx.pal vanillara
Here are the logs for the demo soviet mission:
DEBUG: RA95 - Starting up.
INFO : Searching the following paths for path config data:
argv: '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
binary: '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
default data: '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/share/vanillara'
default user: '/Users/x/Library/Application Support/Vanilla-Conquer/vanillara'
INFO : Read only data directory is set to '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
INFO : Read/Write user data directory is set to '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
INFO : Created SDL2 fullscreen window in 0x0
INFO : pixel format: SDL_PIXELFORMAT_ARGB8888 (32 bpp)
INFO : SDL2 drivers available: (user preference 'default')
INFO : metal
INFO : opengl
INFO : opengles2
INFO : software
INFO : Initialized SDL2 driver 'metal'
INFO : flags:
INFO : SDL_RENDERER_ACCELERATED
INFO : SDL_RENDERER_TARGETTEXTURE
INFO : max texture size: 16384x16384
INFO : 6 texture formats supported: (user preference 'SDL_PIXELFORMAT_UNKNOWN')
INFO : SDL_PIXELFORMAT_ARGB8888 (selected)
INFO : SDL_PIXELFORMAT_ABGR8888
INFO : SDL_PIXELFORMAT_YV12
INFO : SDL_PIXELFORMAT_IYUV
INFO : SDL_PIXELFORMAT_NV12
INFO : SDL_PIXELFORMAT_NV21
INFO : scaler set to 'nearest'
DEBUG: Loaded scenario file
DEBUG: scu01ea.ini
Segmentation fault: 11
and the alied mission
DEBUG: RA95 - Starting up.
INFO : Searching the following paths for path config data:
argv: '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
binary: '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
default data: '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/share/vanillara'
default user: '/Users/x/Library/Application Support/Vanilla-Conquer/vanillara'
INFO : Read only data directory is set to '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
INFO : Read/Write user data directory is set to '/Users/x/CLionProjects/Vanilla-Conquer/build/vanillara.app/Contents/MacOS'
INFO : Created SDL2 fullscreen window in 0x0
INFO : pixel format: SDL_PIXELFORMAT_ARGB8888 (32 bpp)
INFO : SDL2 drivers available: (user preference 'default')
INFO : metal
INFO : opengl
INFO : opengles2
INFO : software
INFO : Initialized SDL2 driver 'metal'
INFO : flags:
INFO : SDL_RENDERER_ACCELERATED
INFO : SDL_RENDERER_TARGETTEXTURE
INFO : max texture size: 16384x16384
INFO : 6 texture formats supported: (user preference 'SDL_PIXELFORMAT_UNKNOWN')
INFO : SDL_PIXELFORMAT_ARGB8888 (selected)
INFO : SDL_PIXELFORMAT_ABGR8888
INFO : SDL_PIXELFORMAT_YV12
INFO : SDL_PIXELFORMAT_IYUV
INFO : SDL_PIXELFORMAT_NV12
INFO : SDL_PIXELFORMAT_NV21
INFO : scaler set to 'nearest'
DEBUG: Loaded scenario file
DEBUG: scg02ea.ini
DEBUG: AnimClass::operator new FAILED
Segmentation fault: 11
~The bug seems to be activated when an MVC is destroyed. I can reproduce by force attacking my own MVC.~
(on acc6fa62372328b8025da11a3e24102f69cd9e60)
attempting to turn off compiler flags by adding
#SET(CMAKE_CXX_FLAGS "-O0")
#SET(CMAKE_C_FLAGS "-O0")
in CMakeLists.txt
made no difference.
As suggested on the discord, tried the fist mission on the soviet campaign where destroying barrels caused an issue. possibly related to https://github.com/TheAssemblyArmada/Vanilla-Conquer/issues/212.
This is not as reproducible as I originally thought, after rebuilding (or time passing) the error no longer reliably happens.
I was able to get one stack-trace:
Maintenance_Callback() soundio_openal.cpp:691
Sound_Callback() soundio_openal.cpp:605
Call_Back() conquer.cpp:1369
Main_Loop() conquer.cpp:1868
Main_Game(int, char **) conquer.cpp:317
main startup.cpp:476
start 0x000000011eb4d51e
~~where
st->Format
was causing trouble~~
on the allied demo mission I can get this, after destroying some barrels
AnimClass::AnimClass(AnimType, unsigned int, unsigned char, char) anim.cpp:582
AnimClass::AnimClass(AnimType, unsigned int, unsigned char, char) anim.cpp:582
AnimClass::Middle() anim.cpp:1142
AnimClass::AI() anim.cpp:877
LogicClass::AI() logic.cpp:351
Main_Loop() conquer.cpp:1835
Main_Game(int, char **) conquer.cpp:317
main startup.cpp:476
start 0x00000001116be51e
with Exception: EXC_BAD_ACCESS (code=1, address=0x0)
~where if I had to guess, Anims.ID(this)
is causing issues since the debugger says this=NULL
.~
since this seems to be a momory issue I'm trying to run with saitizers, though the options are limited for Mac.
I get the following warnings
straw.cpp
Stack-use-after-scope on address 0x7ff7bcb3ad90 at pc 0x00010394307f bp 0x7ff7bcb3aa40 sp 0x7ff7bcb3aa38
READ of size 8 at 0x7ff7bcb3ad90 thread T0
0x10394307e Straw::~Straw straw.cpp:64
0x103952acd FileStraw::~FileStraw xstraw.cpp:146
0x103952b04 FileStraw::~FileStraw xstraw.cpp:140
0x1034cf92a MixFileClass::MixFileClass mixfile.h:467
0x1034ce464 MixFileClass::MixFileClass mixfile.h:376
0x10361e840 Init_Bootstrap_Mixfiles init.cpp:2315
0x103611651 Bootstrap init.cpp:2442
0x10360ff4f Init_Game init.cpp:188
0x1034b14d4 Main_Game conquer.cpp:188
0x103791e9d main startup.cpp:476
0x108ed251d start
Address 0x7ff7bcb3ad90 is located in stack of thread T0 at offset 496 in frame
0x1034ce47f MixFileClass::MixFileClass mixfile.h:376
Stack-use-after-scope on address 0x7ff7bcb3ad98 at pc 0x000103943206 bp 0x7ff7bcb3a9a0 sp 0x7ff7bcb3a998
READ of size 8 at 0x7ff7bcb3ad98 thread T0
0x103943205 Straw::Get_From straw.cpp:89
0x1039430c1 Straw::~Straw straw.cpp:64
0x103952acd FileStraw::~FileStraw xstraw.cpp:146
0x103952b04 FileStraw::~FileStraw xstraw.cpp:140
0x1034cf92a MixFileClass::MixFileClass mixfile.h:467
0x1034ce464 MixFileClass::MixFileClass mixfile.h:376
0x10361e840 Init_Bootstrap_Mixfiles init.cpp:2315
0x103611651 Bootstrap init.cpp:2442
0x10360ff4f Init_Game init.cpp:188
0x1034b14d4 Main_Game conquer.cpp:188
0x103791e9d main startup.cpp:476
0x108ed251d start
Address 0x7ff7bcb3ad98 is located in stack of thread T0 at offset 504 in frame
0x1034ce47f MixFileClass::MixFileClass mixfile.h:376
with
add_compile_options(-fsanitize=address -fsanitize-recover=address)
add_link_options(-fsanitize=address -fsanitize-recover=address)
with options detect_stack_use_after_return=false halt_on_error=0
looks like the sanitizer warning is unrelated to the animation crash. if you remove the code that causes the warning, you can run up the the animation crash without any warnings.
the animation crash is happening because FixedHeapClass::Allocate
is failing to allocate:
ActiveCount= 200
TotalCount= 200
there seems to be a hacky fix to rules.cpp
with
AnimMax = max(AnimMax, 800);
since this seems to work on other systems, perhaps there is an issue in deallocation
After fixing the data file path issue for macOS (pull request pending), I encountered the same issue while playing the first mission. Do you want to commit your change? Looks uncritical for me.
Edit: I found out that my crashes are unrelated to your problem. Mine are related to OpenAL. Cmake is using the OpenAL lib bundles with macOS by default, which led to issues here. I have installed the recent openal-soft libs with MacPorts and added the parameter "-DCMAKE_FIND_FRAMEWORK="NEVER"" to the cmake command in order to fix my issue.
excellent! I have occasionally been getting the OpenAL bug as well but less frequently. I want to make sure things are actually deallocating before I commit the change.
It looks like things are getting deallocated and the the max animations doesn't go much over 200.
It seems like in general it might be better to try and increase the size of the heap if more elements are allocated then there is size: https://github.com/TheAssemblyArmada/Vanilla-Conquer/blob/vanilla/redalert/heap.cpp#L217-L226 . It might be good to not use a "fixed" heap for this, since no matter what TotalCount
is set to there is probably always some number of barrels that could explode that would overwhelm TotalCount
and cause a similar issue.
small example of what might not be working in clang
#include <iostream>
using namespace std;
class car {
string name;
public:
car(string a, int n) {
cout << "Constructor called" << endl;
}
void *operator new(size_t size){
return NULL;
}
};
int main() {
// Using new keyword
car *p = new car("Honda", 2017);
cout << "*p = " << p << endl;
// p->display();
}
where it seems as if clang is trying to set up the string
If this does turn out to be a valid fix, we should search for other places that should have this keyword.
I believe this should now be fixed due to #817 being merged. could you confirm?