search

DynamoRIO / drmemory

Memory Debugger for Windows, Linux, Mac, and Android
Other
2.44k stars 262 forks source link

Visual Studio 2019 pbm #2352

Closed cedric-ca closed 3 years ago

cedric-ca commented 3 years ago

Hi,

We moved to Visual Studio 2019 and encounter different problems:

  1. We have to set /DEBUG:FASTLINK and not another one, else it won't work.
  2. We try to analyze COM dll through Excel automation, but it doesn't work even if we use the nudge option. It never really worked with Excel 2010 and Visual Studio 2017. It's worth with Excel 2016 and Visual Studio 2019.
  3. Under Windows Win 10-1809 x64 DrMemory crash.

Can you briefly explain how to build a valid DrMemory under Visual Studio (latest available version I will move to 2019) with the corresponding Dynamorio version, so I can find a solution. Although can you give me tips on where to seek.

Thanks

Cédric

derekbruening commented 3 years ago

We have to set /DEBUG:FASTLINK and not another one, else it won't work.

At least with prior versions, fastlink produces a partial pdb without line number information: #1866, #2159. Thus the docs https://dynamorio.org/drmemory_docs/page_prep.html#sec_prep_windows say:

For Visual Studio 2017 it should say "Generate Debug Information optimized for sharing and publishing (/DEBUG:FULL)" – it should not say "Generate Debug Information (/DEBUG)" nor "Generate Debug Information optimized for faster links (/DEBUG:FASTLINK)".

Please elaborate on "won't work".

cedric-ca commented 3 years ago

If we select another debug flag than FASTLINK under vs 2019, DrMemory crash. With VS2017 it worked.

Please how can I debug DrMemory?

derekbruening commented 3 years ago

I can't reproduce a problem when building with VS2019 minimally from the command line: VS2019-built applications work fine.

D:\derek\dr\test>cl /version
Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28325 for x64

D:\derek\dr\test>cl /Zi /FefreeVS2019.exe d:\derek\drmemory\git\src\tests\free.c

Explicitly passing /debug:full also works fine:

D:\derek\dr\test>cl /Zi /FefreeVS2019.exe d:\derek\drmemory\git\src\tests\free.c /link /debug:full

Can you confirm that just cl /Zi from a VS2019 command prompt works fine on a tiny program? And if it does, but doesn't work when building inside the IDE, are there other flags enabled causing a problem?

derekbruening commented 3 years ago

Are you building 32-bit or 64-bit? I tested 64-bit.

cedric-ca commented 3 years ago

Hi derek,

Sorry for the late answer, but I was on holiday. The problem we encounter is when we use DrMemory in the following manner:

With a 32-bit vs2017 build it sometimes found leaks, but not always. With a 32-bit vs2019 build it doesn't.

We need to build with (/DEBUG:FASTLINK) else DrMemory crash.

My question is, is-it a good way to try to analyse Com objects with DrMemory in such a way Do you have any suggestion on how we could do this?

For information, we do not have any problem when we launch DrMemory directly on a C++ exe build with VS2019.

Thanks

derekbruening commented 3 years ago
  • Unfortunately it doesn't find any leak, even on a simple C++leaking function

Is the pointer to the memory out of scope? If the nudge arrives while an anchor pointer still has defined state in the stack frame it will not be reported as a leak.

We need to build with (/DEBUG:FASTLINK) else DrMemory crash.

A callstack of the crash would help.

My question is, is-it a good way to try to analyse Com objects with DrMemory in such a way Do you have any suggestion on how we could do this?

In theory, if the application is using the system heap that DrM intercepts, it should work. The crash with symbols is disturbing: but if it can't be reproduced on something smaller, it may not be easy to figure out, unless the callstack points at something obvious.

cedric-ca commented 3 years ago

Hi Dereck,

I made some more investigation and found out that DrMemory is crashing (with DEBUG:FULL and DEBUG flags) when we do include cppunit 3rdparty (I tried with version 1.14.0 and 1.15.1). I made a sample you can try testDrMemory.zip 1.15.1.zip

In those zip: I made a "Release Quantify x86" build for both solutions (target files are ProjectName_q). In cppunit, only the build of cppunit.vcxproj is needed (I upgraded it to VS2019, the solution is in examples folder) I have configure testDrMemory to find cppunit in c:\3rdparties\vc19 testDrMemory solution contains a static lib with a memory leak and an exe which include cppunit, the static lib and although has a memory leak.

If you run DrMemory on test_q.exe with "-report_leak_max -1 -report_max -1 -no_check_gdi" options you will be able to reproduce the crash.

VS2019 version is 16.8.4 Target servers: Windows Server 2008 R2, Windows Server 2016, Windows Server 2012 R2 and Windows 10

Cédric

cedric-ca commented 3 years ago

Hi Derek,

I forgot to say that DrMemory version is 2.3.0-1 It doesn't crash and finds the leak with DEBUG:FASTLINK but no function name are displayed (expected)

cedric-ca commented 3 years ago

Hi Derek,

I tried to launch DrMemory on CppUnitTestMain.exe with release Quantify config and it crash directly.

cedric-ca commented 3 years ago

Hi Derek,

Just to know if you had the time to have a look?

Cedric

cedric-ca commented 3 years ago

Fixed with VS 2019 version 16.10