"Help" option crashes external project

[dogbiscuituk]

Trying to run my first "external" CS project, I copied just the Simple1 files to a new solution, making all the adjustments necessary to link to the correct prebuilt CS library, as detailed in the CS manual.
The result is a new Simple1 which runs perfectly correctly, in either Debug or Release.
However there is a problem when I run the Debug build with the "-help" option. The first few Help lines appear correctly on the console like this:

Win32-specific options:
  -[no]console       Create a debug console (default = yes)
Options for Crystal Space 2D OpenGL graphics driver for Win32:
  -depth=<val>       Display depth (32)
  -[no]fs            Fullscreen if available (no)
  -mode=<val>        Window size or resolution (640x480)

Then I get a "Debug assertion failed" dialog with these details in it:
Program: <path to my exe>
File: dbgdel.cpp
Line: 52
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
Looking into the call stack a little, this seems to be happening just prior to exiting

csCommandLineHelper::Help (iPluginConfig* config)

in file cmdhelp.cpp, having successfully printed three items, and while trying to destroy a csVariant object.
Have I missed some or other setting to enable correct function of memory management between my external project and the CS lib?

I am using:
MS Windows XP Pro 2002 SP2
MS Visual Studio.NET 2003 (aka "VC7")
CS Pseudo Stable Release (0.99 from 3 September 2005)

[sunshine]

Does the same problem occur with the simple1 included with CS? Can you step through the Help() function an narrow down the problem more precisely?

[dogbiscuituk]

Does the same problem occur with the simple1 included with CS?

No, that runs ok!

Can you step through the Help() function an narrow down the problem more precisely?

Yes, here's the call stack ("WorldOne" is the solution name & project name):
msvcr71d.dll!operator delete(void * pUserData=0x00f251d0)  Line 52 + 0x51
msvcr71d.dll!operator delete[](void * p=0x00f251d0)  Line 21 + 0x9
WorldOne.exe!csVariant::~csVariant()  Line 62 + 0x26
WorldOne.exe!csCommandLineHelper::Help(iPluginConfig * config=0x00dec618)  Line 73 + 0xf
WorldOne.exe!csCommandLineHelper::Help(iObjectRegistry * object_reg=0x00abe998, iCommandLineParser * cmdline=0x00000000)  Line 109 + 0xe
WorldOne.exe!csApplicationFramework::Main(int argc=2, char * * argv=0x00aa5d70)  Line 123 + 0xd
WorldOne.exe!csApplicationRunner<Simple>::Run(int argc=2, char * * argv=0x00aa5d70)  Line 419 + 0x10
WorldOne.exe!main(int argc=2, char * * argv=0x00aa5d70)  Line 263 + 0xd
WorldOne.exe!mainCRTStartup()  Line 398 + 0x11
kernel32.dll!7c816d4f()    
ntdll.dll!7c915b4f()    
kernel32.dll!7c8399f3()
The third line above is in the (inline) csVariant destructor in pluginconfig.h. Inspecting "this" object reveals:
this    0x0012fb60
type    CSVAR_STRING
v.s     0x00f251d0 "640x480"

[sunshine]

It's pretty difficult to see how this could go wrong. csVariant makes a copy of the string passed to it and then frees that copy at destruction time. The only obvious way this could go awry is if the code does varlant.SetString(variant.GetString()), but that isn't happening in this case.

The crash seems to indicate some sort of heap/memory corruption, but it's not obvious how csVariant would be responsible for it. Is your code 100% identical to the original simple1 code?

[dogbiscuituk]

Is your code 100% identical to the original simple1 code?

Both simple1.cpp and simple1.h are 100% identical - I just copied Jorrit's original files into the new solution folder.
Where they do differ is in the compiler & linker options set for each - necessarily so, since the aim is to create an "external" project - so the command lines supplied to the MS C++ compiler & linker differ:
(appsimple1 compiler)
/Og /Ob2 /Oi /Ot /Oy /GL /G5 /I "." /I "..\.." /I "..\..\include" /I "..\..\include\csutil\win32" /D "NDEBUG" /D "_WINDOWS" /D "WIN32" /D "CS_WIN32_CSCONFIG" /D "__CRYSTAL_SPACE__" /D "_MBCS" /GF /FD /EHsc /MD /Gy /Fp"..\..\out\release\build\appsimple1\appsimple1.pch" /Fo"..\..\out\release\build\appsimple1\\" /Fd"..\..\out\release\build\appsimple1\appsimple1.pdb" /W3 /nologo /c /Wp64 /Zi
(appsimple1 linker)
/OUT:"..\..\simple1.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"..\..\libs\csutil\win32\libs" /NODEFAULTLIB:"LIBC" /NODEFAULTLIB:"LIBCD" /NODEFAULTLIB:"LIBCMT" /NODEFAULTLIB:"LIBCMTD" /DEBUG /PDB:"..\..\out\release\build\appsimple1\appsimple1.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 advapi32.lib user32.lib gdi32.lib shell32.lib zlib.lib  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib "\Work\Crystal Space\Cs\out\release\libs\libcrystalspace.lib" "\Work\Crystal Space\Cs\libs\csutil\win32\libs\zlib.lib"
(WorldOne compiler)
/Og /Ob2 /Oi /Ot /Oy /GL /G5 /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "CS_WIN32_CSCONFIG" /D "__CRYSTAL_SPACE__" /D "CS_DEBUG" /D "_MBCS" /GF /FD /EHsc /MDd /Gy /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /nologo /c /Wp64 /Zi
(WorldOne linker)
/OUT:"Debug/WorldOne.exe" /INCREMENTAL:NO /NOLOGO /DEBUG /PDB:"Debug/WorldOne.pdb" /SUBSYSTEM:CONSOLE /LTCG /MACHINE:X86 libcrystalspace_d.lib  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib "\Work\Crystal Space\Cs\out\debug\libs\libcrystalspace_d.lib"

[dogbiscuituk]

Switching the C/C++ Code Generation Runtime Library from "Multi-threaded Debug DLL (/MDd)" to "Multi-threaded DLL (/MD)" causes the problem to go away. That's not an answer, just an interesting & possibly helpful observation!

[sunshine]

This appears to be a bug in CS where it is allocating the string in one heap and then attempting to destroy it in a different heap. We normally work around this issue via reference counting and virtual object destructor. I submitted this on the CS bug tracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=1388079&group_id=649&atid=100649