Handle leak (not our fault) in EnergyLib64 about uiforetw HOT 8 OPEN

I have contacts at Intel so I can pass it along. Does it happen even if the DLL is unloaded? I take it there is no uninitialize function?

Avoiding resource leaks at shutdown is a hassle and sometimes not worth the trouble, but I can report it.

from uiforetw.

Does it happen even if the DLL is unloaded?

Eh, you mean not loaded? No, I don't think so.

I take it there is no uninitialize function?

Nope, no documented function, and no exported function.

Reporting would be nice :)

from uiforetw.

I meant does it happen even if the DLL is loaded and then unloaded.

If you want the Intel developers to investigate you probably need to create a minimal repro (preferably a single source file or a very small project) and precise instructions on how to repro the problem. For instance, specifying where to get App verifier, how to use it, and having something simpler than all of UIforETW to reproduce the problem.

from uiforetw.

I meant does it happen even if the DLL is loaded and then unloaded.

No, if I do a LoadLibrary followed only by a FreeLibrary, then there's no leak.

If you want the Intel developers to investigate you probably need to create a minimal repro (preferably a single source file or a very small project) and precise instructions on how to repro the problem. For instance, specifying where to get App verifier, how to use it, and having something simpler than all of UIforETW to reproduce the problem.

Good idea, seems obvious in retrospect (duh on my part!). I've got a really simple minimal repro already thrown together. Shall I simply paste it into a comment?

from uiforetw.

Pasting into a comment could work, but might be unwieldy by the time you have repro instructions and the necessary build commands. A .zip file with instructions and .vcxproj/.sln files would be one good option, or a github repo to allow tweaking it (I can test the instructions to make sure they work and provide feedback).

Be aware that a handle leak may be by design or at least not treated as high priority. Perfect cleanliness during shutdown is often pointless or not practical (see for example crbug.com/490716 which explicitly recommends calling TerminateProcess rather than paying the cost for a theoretically ideal but sometimes expensive shutdown).

from uiforetw.

Be aware that a handle leak may be by design or at least not treated as high priority. Perfect cleanliness during shutdown is often pointless or not practical (see for example crbug.com/490716 which explicitly recommends calling TerminateProcess rather than paying the cost for a theoretically ideal but sometimes expensive shutdown).

Oh I totally agree, for application-level code, that is. The Intel Power Gadget API is third party code, and this is nowhere documented. If a program loads the library, initializes it, and frees it, then it's dealing with a mystery leak. It's quite easy to make my repro trigger this problem. Here it is leaking 6,730 handles:

6,730, next to Normal is Task Manager's Handles column.

...and all it took was:

    const size_t maxEnergyLib = 10000u;
    for ( size_t i = 0u; i < maxEnergyLib; ++i ) {
        doEnergyLib( );
        }

By leaking thousands of handles, we don't need Application Verifier to demonstrate the presence of a leak, but using Application Verifier will (of course) point to the offending HANDLE's allocation stack.

from uiforetw.

Here's a repo: https://github.com/ariccio/EnergyLibLeak

from uiforetw.

Thanks. I've passed it along. Good work.

from uiforetw.