In the process of looking into this (http://forum.simutrans.com/index.php?topic=12427) issue that seems to arise only with particular objects in a certain pakset, it seems that there is a potential problem with all release (but not debug) builds of Simutrans-Experimental.
Running a release build in Dr. Memory reveals scores of errors such as these:
Error #1: INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]
# 0 Simutrans-Experimental.exe!? +0x0 (0x0042a6fe <Simutrans-Experimental.exe+0x2a6fe>)
# 1 Simutrans-Experimental.exe!? +0x0 (0x0042a678 <Simutrans-Experimental.exe+0x2a678>)
# 2 Simutrans-Experimental.exe!? +0x0 (0x00429d3c <Simutrans-Experimental.exe+0x29d3c>)
# 3 Simutrans-Experimental.exe!? +0x0 (0x00625125 <Simutrans-Experimental.exe+0x225125>)
# 4 Simutrans-Experimental.exe!? +0x0 (0x005c35a1 <Simutrans-Experimental.exe+0x1c35a1>)
# 5 Simutrans-Experimental.exe!? +0x0 (0x005c356a <Simutrans-Experimental.exe+0x1c356a>)
# 6 Simutrans-Experimental.exe!? +0x0 (0x00496dff <Simutrans-Experimental.exe+0x96dff>)
# 7 Simutrans-Experimental.exe!? +0x0 (0x00461108 <Simutrans-Experimental.exe+0x61108>)
# 8 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x757a33aa <KERNEL32.dll+0x133aa>)
# 9 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x77b69f72 <ntdll.dll+0x39f72>)
#10 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x77b69f45 <ntdll.dll+0x39f45>)
Note: @0:00:00.291 in thread 3560
Note: memory was allocated here:
Note: # 0 MSVCR110.dll!operator new +0xe (0x51a4dda7 <MSVCR110.dll+0xdda7>)
Note: # 1 Simutrans-Experimental.exe!? +0x0 (0x0042a5f6 <Simutrans-Experimental.exe+0x2a5f6>)
Note: # 2 Simutrans-Experimental.exe!? +0x0 (0x00429d3c <Simutrans-Experimental.exe+0x29d3c>)
Note: # 3 Simutrans-Experimental.exe!? +0x0 (0x006250e4 <Simutrans-Experimental.exe+0x2250e4>)
Note: # 4 Simutrans-Experimental.exe!? +0x0 (0x005c35a1 <Simutrans-Experimental.exe+0x1c35a1>)
Note: # 5 Simutrans-Experimental.exe!? +0x0 (0x005c356a <Simutrans-Experimental.exe+0x1c356a>)
Note: # 6 Simutrans-Experimental.exe!? +0x0 (0x00496dff <Simutrans-Experimental.exe+0x96dff>)
Note: # 7 Simutrans-Experimental.exe!? +0x0 (0x00461108 <Simutrans-Experimental.exe+0x61108>)
Note: # 8 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x757a33aa <KERNEL32.dll+0x133aa>)
Note: # 9 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x77b69f72 <ntdll.dll+0x39f72>)
Note: #10 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x77b69f45 <ntdll.dll+0x39f45>)
It is impossible to track them down individually because of the absence of debug symbols. However, these errors do not appear in debug builds. I do not know for sure whether this is causing the crash that Junna reported in the other thread, but this seems to be a good place to start.
If anyone has any ideas why this might be happening with release builds but not debug builds, I should be very grateful for any suggestions.
There should be compiler flags to add full optimisation to debug builds.
Yep, get optimization on the debug build, maybe you'll make the bug appear. You might also be using different libraries/includes on debug and release builds, check it out too.
If you (or somebody else) has a linux system running, you could test the program with valgrind. It easily finds such errors.
I have tried Dr. Memory, which I understand is the Windows equivalent of Valgrind, without success, as discussed above. I shall have to try debugging an optimised build to see whether that makes any difference.
valgrind is better than dr memory, but slower. The latter is more installing hooks, more like a profiler, while valgrind is running the code in a virtual machine, and hence can backtrace exactly the reason. Dr. memory may be irritated by things like int arrays, whcere delte [] does not need the [] and hence the compiler may omit it. But then GCC may not show this at all.
Ahh, thank you for that useful insight - I did wonder whether Dr. Memory was not interacting well with a legitimate compiler optimisation technique. This does not explain the crash, however...