why Dr memory recommand building application with static libstdc++ libraries under MinGW?

304 views
Skip to first unread message

asm warrior

unread,
Dec 1, 2013, 3:20:18 AM12/1/13
to drmemor...@googlegroups.com
Hi, I see in the Dr memory document, you recommend linking static libstdc++ libraries. http://drmemory.org/docs/page_prep.html

For MinGW C++ applications, we recommending building with static libstdc++ libraries. Pass -static-libgcc -static-libstdc++ to g++ to request this.

I just test a simple project and see what are the differences with application with shared libstdc++ and static libstdc++ libraries.

Test code:
#include <iostream>
#include <cstring>
using namespace std;

char * f() {
    char * p = new char[100];
    strcpy( p, "foobar" );
    return p;
}

int main() {
    for( int i = 0; i < 10; i++ ) {
        cout << f() << endl;
    }
}

When build with MinGW-Build-4.7.3 (shared libstdc++), I get the result:

Dr. Memory version 1.6.0 build 2 built on Sep  7 2013 03:37:07
Dr. Memory results for pid 7460: "test-memory-leak.exe"
Application cmdline: "test-memory-leak.exe"
Recorded 97 suppression(s) from default D:\DrMemory-Windows-1.6.0-2\bin\suppress-default.txt

Error #1: POSSIBLE LEAK 30 direct bytes 0x014f00f8-0x014f0116 + 0 indirect bytes
# 0 replace_malloc                                     [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 msvcrt.dll!__setargv
# 2 msvcrt.dll!__getmainargs
# 3 pre_cpp_init       
# 4 _fu0___set_invalid_parameter_handler
# 5 KERNEL32.dll!RegisterWaitForInputIdle             +0x48     (0x7c81776f <KERNEL32.dll+0x1776f>)

Error #2: LEAK 100 direct bytes 0x014f04f8-0x014f055c + 0 indirect bytes
# 0 replace_malloc               [d:\drmemory_package\common\alloc_replace.c:2292]
# 1 libstdc++-6.dll!Znwj        +0x26     (0x6fcae8a7 <libstdc++-6.dll+0x6e8a7>)
# 2 main                         [E:/code/cb/test_code/test-memory-leak/main.cpp:13]

===========================================================================
FINAL SUMMARY:

DUPLICATE ERROR COUNTS:
    Error #   2:     10

SUPPRESSIONS USED:

ERRORS FOUND:
      0 unique,     0 total unaddressable access(es)
      0 unique,     0 total uninitialized access(es)
      0 unique,     0 total invalid heap argument(s)
      0 unique,     0 total GDI usage error(s)
      0 unique,     0 total warning(s)
      1 unique,    10 total,   1000 byte(s) of leak(s)
      1 unique,     1 total,     30 byte(s) of possible leak(s)
ERRORS IGNORED:
      5 unique,     5 total,    377 byte(s) of still-reachable allocation(s)
         (re-run with "-show_reachable" for details)
Details: D:\DrMemory-Windows-1.6.0-2\drmemory\logs\DrMemory-test-memory-leak.exe.7460.000\results.txt


When build with TDM-4.8.1 (static libstdc++ library)
Dr. Memory version 1.6.0 build 2 built on Sep  7 2013 03:37:07
Dr. Memory results for pid 4972: "test-memory-leak.exe"
Application cmdline: "test-memory-leak.exe"
Recorded 97 suppression(s) from default D:\DrMemory-Windows-1.6.0-2\bin\suppress-default.txt

Error #1: LEAK 100 direct bytes 0x011b0748-0x011b07ac + 0 indirect bytes
# 0 replace_operator_new_array               [d:\drmemory_package\common\alloc_replace.c:2450]
# 1 f()                                      [E:/code/cb/test_code/test-memory-leak/main.cpp:6]
# 2 main                                     [E:/code/cb/test_code/test-memory-leak/main.cpp:13]

===========================================================================
FINAL SUMMARY:

DUPLICATE ERROR COUNTS:
    Error #   1:     10

SUPPRESSIONS USED:

ERRORS FOUND:
      0 unique,     0 total unaddressable access(es)
      0 unique,     0 total uninitialized access(es)
      0 unique,     0 total invalid heap argument(s)
      0 unique,     0 total GDI usage error(s)
      0 unique,     0 total warning(s)
      1 unique,    10 total,   1000 byte(s) of leak(s)
      0 unique,     0 total,      0 byte(s) of possible leak(s)
ERRORS IGNORED:
      9 potential leak(s) (suspected false positives)
         (details: D:\DrMemory-Windows-1.6.0-2\drmemory\logs\DrMemory-test-memory-leak.exe.4972.000\potential_errors.txt)
      7 unique,     7 total,     52 byte(s) of still-reachable allocation(s)
         (re-run with "-show_reachable" for details)
Details: D:\DrMemory-Windows-1.6.0-2\drmemory\logs\DrMemory-test-memory-leak.exe.4972.000\results.txt

Look, in the later result, the call stack (back trace) show correctly, the function call
# 1 f()                                      [E:/code/cb/test_code/test-memory-leak/main.cpp:6]
Is correctly listed in the report, but in the former test, there is no call-stack mention the f() function.

Thanks.
Yuanhui Zhang
 
 

Derek Bruening

unread,
Dec 2, 2013, 5:30:41 PM12/2/13
to drmemor...@googlegroups.com
Note that older MinGW (4.5.x, e.g.) does not exhibit these problems.  But there are several issues with recent MinGW, as you hit:

1) Symbol mangling for operators is not properly handled: hence the operators are not replaced, causing DrMem to not report certain types of bugs (such as delete vs delete[] mismatch).

2) The FPO opts in the operators can cause missing frames, as you observed.

Hence, the recommendation to use static libstdc++ with MinGW.


--
 
---
You received this message because you are subscribed to the Google Groups "Dr. Memory Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Derek Bruening

unread,
Dec 4, 2013, 2:17:50 PM12/4/13
to drmemor...@googlegroups.com
The latest Dr. Memory builds from http://build.chromium.org/p/client.drmemory/builds/ (r1644+) should work fairly well with shared libstdc++ on MinGW.

- Derek

asm warrior

unread,
Dec 8, 2013, 8:57:26 AM12/8/13
to drmemor...@googlegroups.com


On Thursday, December 5, 2013 3:17:50 AM UTC+8, Derek Bruening wrote:
The latest Dr. Memory builds from http://build.chromium.org/p/client.drmemory/builds/ (r1644+) should work fairly well with shared libstdc++ on MinGW.

- Derek

Hi, Derek, Many thanks. I have checked the "Email notification", but I don't receive emails about your reply. So, sorry for the late reply.

I have tried the latest DrMemory from the above link, and yes, it does not have the issue now, Many thanks for your work!

Yuanhui Zhang

Reply all
Reply to author
Forward
0 new messages