I have a C++ code base that has been working for a long time. The code base was a legacy VS 2003 set of projects that I recently migrated to VS 2008. The migration seemed
The issue is resolved - and unrelated to chsize
. The linking model to the c-runtime libraries chosen for code generation was set to multi-threaded debug (/MTd) for the main project, but multi-threaded debug DLL (/MDd) for all of the projects in the solution that it linked to. Changing to /MDd resolved the issue.
I am familiar with these linking issues and am generally careful to set them properly, but because this was an upgrade of a working project from an earlier version of Visual Studio with no changes, I did not think to look down this road. I did not investigate how or why the setting was changed (or even if it was set this way in the previous version but did not cause problems).
Found this problem in my code too. Main program need to linked with shared library which build with MT. When file handler opened in main program passed to shared library's function, _VALIDATE_RETURN((_osfile(fh) & FOPEN), EBADF, -1) in setmode.c of CRT crashed the program.
Debug the _osfile in assembly mode, osfile lookup file handler in table __pioinfo (01802EEDB0h). Well it's fixed area in statically linked CRT. And another __pioinfo in the main program is another address 01E619540h. In one word, if two module need to shared global data, can not build with MT model.
I just want to optimize the shared library with static compilation, some hard to notice bugs could happen. Seems GCC's force shared or static makes sense in most situation.