msdia90.dll (32-bits) out-of-memory with chrome.dll

[Arnaud Diederen]

Hello,

Our product allows users to view information extracted from a binary file,
including the information that could be found in an associated PDB.

Recently, some of our users have started trying to inspect Google
Chrome's companion DLL (chrome.dll).

That DLL has a relatively big PDB (400+MB), which has been known to cause some
problems to tools that access it. E.g., <https://connect.microsoft.com/VisualStudio/feedback/details/773358/access-violation-read-av-in-msdia110-dll-getdata-getclassinfo>

While the access violation described in the link above is certainly annoying,
we are experiencing an issue of a different nature.

Our program needs to go through (iterating) all types, globals, functions,
... and that's causing the DIA SDK to allocate huge amounts of memory.

At some point, Windows 7 fails allocating memory to our program: its 32-bit
address range is fully used.

Note that I am positive we call Release() on every DIA object we allocate:
when Release()-ing the IDiaSession, the memory usage of our program drops to
~400MB.

(Which it wouldn't do if there were still un-Released() DIA objects (it appears
to be enough to have forgotten to release, e.g., a single IDiaSymbol for the
whole memory to remain used))

So, the problem is /not/ that we don't Release() the DIA object handles.

And the problem is not that DIA leaks memory either: if it did,
the memory would not be released at IDiaSession->Release()-time.

Therefore, I can only guess that memory is necessary for
DIA to function properly.

----

I have a couple questions:

1) (I doubt it, but..) Are there 'tricks' to make DIA consume less memory, or
release parts of it that it could find are not really needed at a given time?

2) After our program hits an out-of-mem, and IDiaSession->Release() is called,
the memory as reported by Process Explorer drops from ~4GB -> ~400MB. So, the
whole DIA memory is freed. However, performing a large malloc() (e.g., 200MB)
afterwards will fail, reporting another out-of-memory. I'm not very familiar
with how Windows handles its heap(s), but I suspect that address space remains
reserved (or something similar).

I've read some documentation:
- http://msdn.microsoft.com/en-us/library/aa366887%28VS.85%29.aspx
- http://msdn.microsoft.com/en-us/library/ms810603.aspx
- http://msdn.microsoft.com/en-us/library/windows/desktop/aa366597(v=vs.85).aspx

..but couldn't quite find the an answer there.
Would I have missed an interesting article, that might explain what
we are experiencing?

Any help or pointer is most, most welcome!

Best regards,
Arnaud Diederen.