by unknownfile at 6:30 PM EST on November 17, 2009
most likely debug shit left behind on the disk before shipping
The crashing by MegaByte at 11:28 PM EST on November 18, 2009
If it's crashing with a release build, but not the debug, that often means you've got a buffer overrun somewhere. It doesn't kill the program in debug mode since debug adds buffer areas around your memory allocations, but without the buffer, it crashes in release mode. Anyway, testing out a compile for myself...
Update: Okay, after fiddling with all the library settings, I got it to compile. The release build doesn't seem to even be recognized by Winamp. In the debug build, it was crashing whenever I loaded a Wacky Wheels file. But I could ignore the crash and continue execution through MSVC, and the file played. Doom played without crashing. Here's a stack trace for the crash:
msvcr90d.dll!_free_dbg_nolock(void * pUserData=0x160f60e0, int nBlockUse=1) Line 1371 + 0x3b bytes C++ msvcr90d.dll!_free_dbg(void * pUserData=0x160f60e0, int nBlockUse=1) Line 1258 + 0xd bytes C++ msvcr90d.dll!free(void * pUserData=0x160f60e0) Line 49 + 0xb bytes C++ in_sqf.dll!operator delete(void * pointer=0x160f60f0) Line 119 + 0xc bytes C++ in_sqf.dll!Seq_MID::`scalar deleting destructor'() + 0x3c bytes C++ in_sqf.dll!MainSystem::unloadMidi(Sequencer * a_Midi=0x160f60f0) Line 463 + 0x34 bytes C++ in_sqf.dll!tolua__MainSystem_unloadMidi00(lua_State * tolua_S=0x0721eb98) Line 819 C++ in_sqf.dll!luaD_precall(lua_State * L=0x0721eb98, lua_TValue * func=0x042993a8, int nresults=0) Line 319 + 0x16 bytes C in_sqf.dll!luaV_execute(lua_State * L=0x0721eb98, int nexeccalls=1) Line 587 + 0x14 bytes C in_sqf.dll!luaD_call(lua_State * L=0x0721eb98, lua_TValue * func=0x04299398, int nResults=0) Line 377 + 0xb bytes C in_sqf.dll!f_call(lua_State * L=0x0721eb98, void * ud=0x006777c8) Line 800 + 0x16 bytes C in_sqf.dll!luaD_rawrunprotected(lua_State * L=0x0721eb98, void (lua_State *, void *)* f=0x6c356b90, void * ud=0x006777c8) Line 118 + 0x1f bytes C in_sqf.dll!luaD_pcall(lua_State * L=0x0721eb98, void (lua_State *, void *)* func=0x6c356b90, void * u=0x006777c8, int old_top=48, int ef=0) Line 463 + 0x11 bytes C in_sqf.dll!lua_pcall(lua_State * L=0x0721eb98, int nargs=0, int nresults=0, int errfunc=0) Line 821 + 0x20 bytes C in_sqf.dll!ScriptSystem::runFunction(char * a_Script=0x6c3e631c) Line 29 + 0x12 bytes C++ in_sqf.dll!ScriptSystem::~ScriptSystem() Line 21 C++ in_sqf.dll!ScriptSystem::`scalar deleting destructor'() + 0x2b bytes C++ in_sqf.dll!MainSystem::closeAll() Line 60 + 0x37 bytes C++ in_sqf.dll!MainSystem::~MainSystem() Line 24 C++ in_sqf.dll!MainSystem::`scalar deleting destructor'() + 0x2b bytes C++ in_sqf.dll!getfileinfo(const char * filename=0x00677fec, char * title=0x006783fc, int * length_in_ms=0x0049c85c) Line 245 + 0x34 bytes C++ winamp.exe!0040f023()
Obviously, something is getting deleted that's not supposed to, called from the lua script. I added a line, if(a_Midi != NULL) in MainSystem.cpp before delete a_Midi; to try to get rid of the crash, but it seems that it's not a null pointer problem. I still get the heap corruption error. Given the cast you do in the lua glue code, could it be that it's not really a Sequencer object that you're passing for destruction? I'm not familiar with the code, so I'm not sure what to trace where.
Sorry for the lack of updates. A new girlfriend takes quite a lot of time. Not to mention my graduation project is time consuming.
From what i've noticed it seems to be using 2 heaps(a debug heap and a release heap) at the same time and some files are using the debug heap and some the release heap. It's weird since memory.h is used in every file. If I made the MainSystem g_Sys; object in the winamp plugin as MainSystem* g_Sys; i seem to solve at least one heap corruption. Another thing i figured out that i didn't make a few destructors virtual. I thought making the base destructor virtual was enough, but i ended up changing all destructors virtual. The amount of errors i get is dropping and stability is rising luckily.
The latest version crashes in release mode only if you don't debug it. If i attach it to winamp, it seems to crash on fluidsynth checking all voices. This is weird, since the synth is re-initialized if a file is played and no synth is created if it tries to get information from a different file.
Well, this is better. The release compile works for me now. You've got a mix of Multithreaded and Multithreaded DLL library settings. When I changed them all to be the same thing, I was able to remove the excluded library entry, which could be part of your problem.
Thx for telling. and sorry for lack of updates. I had some distracted side projects and got annoyed by the annoying heap corruption error. The project is not dead, it's just sleeping. New girlfriends can be time consuming(but pleasant:) )
MegaByte,Do you have the updated sln and vcproj file for me?
I was working on reading sdat archives first, then followed by reading brsar archives. The file formats are almost the same in structure with small changes and the endianness being different. All RSEQ files inside brsar's are like a mix of SSEQ and SSAR.
Also the newest version would make some functions for tagging available. Sadly it makes the older SQF files i provided not working anymore or without tags available.