Memory leaks reported by CRT on Windows

[TheMostDiligent]

Description of Issue

We are using OpenUSD on Windows and our standard practice is to enable memory leaks reporting on the application exit:

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

After linking the application with USD libraries (we use dynamic linking), the application reports a lot of memory leaks even before we actually call any USD function. The memory dump looks like this:

...
 Data: <TfDiagnosticType> 54 66 44 69 61 67 6E 6F 73 74 69 63 54 79 70 65 
{601} normal block at 0x000001FDF1CD46A0, 16 bytes long.
 Data: < <              > 20 3C C5 F1 FD 01 00 00 00 00 00 00 00 00 00 00 
{600} normal block at 0x000001FDF1C53C10, 64 bytes long.
 Data: <pgG       R     > 70 67 47 F2 FD 01 00 00 E0 14 52 F2 FD 01 00 00 
{599} normal block at 0x000001FDF1CD19D0, 32 bytes long.
 Data: <TF_DIAGNOSTIC_CO> 54 46 5F 44 49 41 47 4E 4F 53 54 49 43 5F 43 4F 
{598} normal block at 0x000001FDF1CD4290, 16 bytes long.
 Data: < q              > D0 71 CD F1 FD 01 00 00 00 00 00 00 00 00 00 00 
{596} normal block at 0x000001FDF1CD4650, 16 bytes long.
 Data: <                > 18 C1 CC F1 FD 01 00 00 00 00 00 00 00 00 00 00 
{595} normal block at 0x000001FDF1C54190, 64 bytes long.
 Data: <enum pxrInternal> 65 6E 75 6D 20 70 78 72 49 6E 74 65 72 6E 61 6C 
...

Could you please suggest if this is something known and if there is a way to release resource before exiting the app?

[sunyab]

Filed as internal issue #USD-8889

[FlorianZ]

Hi @TheMostDiligent . Thanks for pointing this out! I am personally not familiar with CRT, so I am having a hard time interpreting the memory dump. However, as a general pattern, we do intentionally leak singleton-type data in an effort to work around static destruction order issues. We rely on the operating system to free the memory on process termination. Is this possibly what CRT is pointing out here? If so, this should be harmless, but if it's a different issue we'd love to fix it - if you can provide more info!!

PS: Also, to address your comment regarding not even having called any USD functions. Our plugin system does execute code at library load time, so it's not super surprising that USD already "did something" just by loading it into your process.

[TheMostDiligent]

Hi @FlorianZ! Thanks for looking into this.

I am personally not familiar with CRT, so I am having a hard time interpreting the memory dump.

It is the C run-time library on Windows. What it allows is to track each heap allocations and report all live allocations when the program terminates.

However, as a general pattern, we do intentionally leak singleton-type data in an effort to work around static destruction order issues.

I see, I was expecting something like this. All live heap allocations will be reported, so it is most certain that all leftover singleton allocations will show up. My main issue is that this dump creates so much noise in the log that it becomes virtually impossible to notice true memory leaks.

I was thinking there might be a way to force USD release all allocations. If this is not the case, I don't know if anything can be done here.

[FlorianZ]

Is there a mechanism to suppress specific reports? We use suppression files for external libraries with valgrind and the Clang AddressSanitizer, which are the tools we rely on internally.

[TheMostDiligent]

Is there a mechanism to suppress specific reports?

I don't think it can be done easily.

Thanks for the clarification anyway - I will try to find a way to silence these reports.