DrMemory not spotting symbols in dynamically loaded DLL [Windows]

[Eric Brunel]

Hello all,

I've had a problem with an application I'm developing and I could narrow the issue to one DLL that seems to cause a memory corruption of some kind. So I'm trying to use DrMemory to spot exactly where the problem is.

The context is a bit complicated:

• I'm stuck with Visual C++ 6 for the build. The DLL is integrated in a big toolchain that was built a long time ago with VC6, and changing the build tool for the DLL will most likely require to rebuild everything else.
• For the same reason, I'm stuck with a very old Windows SDK. I actually didn't find any version number for it, but it dates back from February 2003.
• The platform I'm building on is Windows Vista, and everything is 32 bits.

The DLL that seems to cause the issue is actually an external module for the tcl/tk language, and it's loaded dynamically by the language interpreter. So I wrote a tcl/tk script that reproduces the problem, and launched DrMemory on the tcl/tk interpreter, passing this script as parameter.

Everything seems to work fine, and there are actually errors reported about some memory corruption. The problem being, the DLL that causes the issue does not show any symbol: all lines for this DLL show as "module_name.dll!?".

I've of course tried to rebuilt the DLL with debug symbols on. I tried the compile and link options listed in the 'Preparing your application' part of DrMemory's documentation - at least those that are supported by VC6 -, but no change: the symbols are still not showing in DrMemory's report. I also tried all the combinations I could think of with COFF, CV and PDB debug symbols, but the DLL symbols are still not showing. But it seems the symbols are in the DLL; at least, when I ask to produce a PDB file, it is produced, and seems to include the debug symbols. Also, for other DLLs, DrMemory does show the symbols. Here is for example an extract of the final report for one of the memory issues:

Error #29: UNADDRESSABLE ACCESS of freed memory: reading 0x09fcb630-0x09fcb634 4 byte(s)

Error #29: UNADDRESSABLE ACCESS of freed memory: reading 0x09fcb630-0x09fcb634 4 byte(s)

# 0 tkpath031g.dll!?                       +0x0      (0x00529247 <tkpath031g.dll+0x9247>)

# 1 tkpath031g.dll!?                       +0x0      (0x00527df5 <tkpath031g.dll+0x7df5>)

# 2 tcl85t.dll!Tcl_EventuallyFree          +0xb0     (0x100bcd3b <tcl85t.dll+0xbcd3b>)

# 3 tkpath031g.dll!?                       +0x0      (0x00527c54 <tkpath031g.dll+0x7c54>)

# 4 tk85t.dll!Tk_HandleEvent               +0x209    (0x1027bf71 <tk85t.dll+0x5bf71>)

# 5 tk85t.dll!Tk_DestroyWindow             +0x2f9    (0x102e4289 <tk85t.dll+0xc4289>)

# 6 tk85t.dll!Tk_DestroyWindow             +0x200    (0x102e4190 <tk85t.dll+0xc4190>)

# 7 tk85t.dll!Tk_SafeInit                  +0x8f5    (0x102e601f <tk85t.dll+0xc601f>)

# 8 tk85t.dll!TkDeleteThreadExitHandler    +0x1c2    (0x1027cf17 <tk85t.dll+0x5cf17>)

# 9 tcl85t.dll!Tcl_FinalizeThread          +0x54     (0x100627b4 <tcl85t.dll+0x627b4>)

#10 tcl85t.dll!Tcl_Finalize                +0xbd     (0x100626f0 <tcl85t.dll+0x626f0>)

#11 tcl85t.dll!Tcl_Exit                    +0x49     (0x100625b6 <tcl85t.dll+0x625b6>)

#12 tcl85t.dll!TclDumpMemoryInfo           +0x3135   (0x1001c095 <tcl85t.dll+0x1c095>)

#13 tcl85t.dll!Tcl_ListMathFuncs           +0x6c6    (0x10012540 <tcl85t.dll+0x12540>)

#14 tcl85t.dll!Tcl_ExprObj                 +0x2f6f   (0x1006642f <tcl85t.dll+0x6642f>)

#15 tcl85t.dll!Tcl_ExprObj                 +0x6c3    (0x10063b83 <tcl85t.dll+0x63b83>)

#16 tcl85t.dll!TclEvalObjEx                +0x375    (0x10014166 <tcl85t.dll+0x14166>)

#17 tcl85t.dll!Tcl_EvalObjEx               +0x17     (0x10013deb <tcl85t.dll+0x13deb>)

#18 tk85t.dll!Tk_MainEx                    +0x2016   (0x102a4327 <tk85t.dll+0x84327>)

#19 tk85t.dll!TkWinHandleMenuEvent         +0x2e8    (0x102342aa <tk85t.dll+0x142aa>)

The problematic DLL is tkpath031g.dll. As you can see, all symbols are there, except those for the DLL that I'm trying to debug…

I've been working on that for quite some time now, but I just don't have any ideas left for things to try. Does anybody have any idea about why the symbols from the DLL would not show? As long as they don't, I'm stuck: I just can't figure out where the memory corruption issue happens.

Thanks.

 - Eric -

[Derek Bruening]

To read symbols on Windows, Dr. Memory uses either the dbghelp library for PDB info or uses the PECOFF symbol table along with DWARF debug info (targeting MinGW binaries).  The code is in the drsyms library: https://github.com/DynamoRIO/dynamorio/tree/master/ext/drsyms.  Dr. Memory ships with a standalone symbol query utility, bin/symquery.exe.  I would suggest running symquery on your library and stepping through the symquery and drsyms code in a debugger to find the precise error codes from the dbghelp routines, if symquery's own verbose info is not enough.

Although we are not aware of any such thing, perhaps there is some older PDB format that is not supported by recent versions of dbghelp?  Using an older dbghelp could solve the problem, but drsyms may complain if it's too old, as it wants a newer version for certain features.  This is speculation: best to figure out the exact failure reason.

--

---
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-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Brunel]

Thanks for your answer.

I did run symquery.exe on my library and it seems it does see the symbols in it without problem. I even ran it in the very same directory where I execute DrMemory, and it works too. But I still don't get symbols in DrMemory's final report… I really don't know what's going on here.

Anyway, I actually figured out tcl/tk has its own memory management routines and that DrMemory will probably be of very little help with the issue I'm investigating about. So finally, no big deal on my side.

Thanks anyway!

To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.