INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]

[jamespetts]

In the process of looking into this 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:

Code Select Expand


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.

[prissi]

There should be compiler flags to add full optimisation to debug builds.

[Markohs]

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.

[Dwachs]

If you (or somebody else) has a linux system running, you could test the program with valgrind. It easily finds such errors.

[jamespetts]

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.

[prissi]

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.

[jamespetts]

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...