False positives with MinGW g++ 8.2.0

[nuomnicron]

I have a very simple bit of code I am trying to use as a teaching example.

#include <iostream>
int main()  {
	int* array = new int[10];

	for (int i = 0; i <= 9; i++) {
		std::cout << array[i] << std::endl;
	}

	delete[] array;
}

When I initially ran DR Memory I got a reasonable result saying UNINITIALIZED READ.

However my students got results of UNADDRESSABLE ACCESS, UNINITIALIZED READ and POSSIBLE LEAK.

I realized I was using an older version of the g++ compiler (7.3.0) than they were. I updated to 8.2.0 (using mingw) and now I get the same error as they do. Same code, same version of dr memory (2.2.0), only thing that changed for me was removing the old mingw and installing a newer one.

[Carrotman42]

What is the difference in the generated code between the two compiler versions?

[nuomnicron]

I apologize for not responding as quickly as you did (thank you for that). I've attached the 2 compiled code versions

Source_.zip

Let me know if you need any additional information

[derekbruening]

The mingw libraries sometimes do things that look suspicious to Dr. Memory, and it is not easy to keep up with them with the project being understaffed. I assume that if you build the same code with MSVC or on WSL or Linux or Mac no extra errors are reported: it's all in the mingw library code.

Maybe the possible leak you saw is this one: #2228. I would guess that all of the extra errors have callstacks composed mostly of mingw libraries. Unfortunately mingw is probably the least well supported toolchain for us. We could use help from new contributors in maintaining mingw support.

[derekbruening]

If you could paste in the error reports for what you believe are either errors in the mingw libraries and not in your app (and thus best to hide, even if real errors) or are false positives: the ones you mention as "results of UNADDRESSABLE ACCESS, UNINITIALIZED READ and POSSIBLE LEAK". We would want to see the full report (callstack and notes) for each to be sure that someone who looks at this is reproducing the same thing.

[nuomnicron]

Again thank you for getting back to me so quickly, it's really impressive

I made the code even simpler to reproduce the error. I am calling new int[10], then delete[] (I've also included my code). I've included the asm code as well as the Dr Memory output for both the expected results and false positive.

MinGW is from https://nuwen.net/mingw.html and is the latest

FalsePositive.zip

[derekbruening]

Easier to see inline:

Error #1: UNADDRESSABLE ACCESS beyond top of stack: reading 0x000000000079fb30-0x000000000079fb38 8 byte(s)
# 0 ___chkstk_ms                            [../../../src/libgcc/config/i386/cygwin.S:132]
# 1 _pei386_runtime_relocator               [../../src/mingw-w64-crt/crt/pseudo-reloc.c:472]
# 2 __tmainCRTStartup
# 3 .l_start
# 4 KERNEL32.dll!BaseThreadInitThunk       +0x13     (0x00007ffda1574034 <KERNEL32.dll+0x14034>)
Note: @0:00:00.277 in thread 12980
Note: 0x000000000079fb30 refers to 664 byte(s) beyond the top of the stack 0x000000000079fdc8
Note: instruction: or     $0x0000000000000000 (%rcx) -> (%rcx)

Error #2: POSSIBLE LEAK 23 direct bytes 0x0000000001a201c0-0x0000000001a201d7 + 0 indirect bytes
# 0 replace_malloc                    [d:\drmemory_package\common\alloc_replace.c:2577]
# 1 msvcrt.dll!realloc               +0x183    (0x00007ffda3c79b54 <msvcrt.dll+0x19b54>)
# 2 msvcrt.dll!unlock                +0x444    (0x00007ffda3c9b1f5 <msvcrt.dll+0x3b1f5>)
# 3 msvcrt.dll!_getmainargs          +0x30     (0x00007ffda3c67991 <msvcrt.dll+0x7991>)
# 4 pre_cpp_init
# 5 msvcrt.dll!initterm              +0x42     (0x00007ffda3c9a0e3 <msvcrt.dll+0x3a0e3>)
# 6 __tmainCRTStartup
# 7 .l_start
# 8 KERNEL32.dll!BaseThreadInitThunk +0x13     (0x00007ffda1574034 <KERNEL32.dll+0x14034>)

Xref #2226 for the chkstk: probably related.

The leak is #781: looks like the symbol name has changed so it does not match the default suppression anymore. You can fix that locally by removing the underscore from __getmainargs in bin64/suppress-default.txt.

[wiluite]

Hello. According to Error 1. I noticed that Dr. Memory 1.11.latest_build and older versions do not complain about Error 1 (at "empty" executable generated from : [void main() {return 0;}] ) with no difference which particular 64-bit MINGW compiler was applied. Starting from 2.0, DrM complains about the executable produced by any (checked) 64-bit MINGW compiler.

Any DrM does not complain about executable built by 32-bit MINGW compiler.