False positives in Wininet libraries (VS 2013) ?

False positives in Wininet libraries (VS 2013) ?

Hi,

The release notes for XE 2013 SP1 mention that some false positives may show up when using the C++ Runtime in Visual Studio 2012: I imagine that also applies to VS 2013. Is this what I am seeing here ?

    P31: Error: Memory leak
     P31.99: Memory leak: 720 Bytes: New
    (omitted ....) Error X106: Allocation site: Function post: Module D:\Source\license system\Win32\Debug\license_test.exe
      Code snippet:
       125  
       126  again:
      >127      if (!HttpSendRequest(request_handle, NULL, 0, data, data.len()))
       128      {
       129          std::cout << "HTTP Request Status (POST): " << error() << std::endl;

      Stack (1 of 1 instance(s))
      >WININET.dll!CreateInstance - C:\Windows\syswow64\WININET.dll:0x14cb1
       WININET.dll!InitializeSocket - C:\Windows\syswow64\WININET.dll:0x14bd0
       WININET.dll!Connect_Start - C:\Windows\syswow64\WININET.dll:0x140bd
       WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x13ca4
       WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
       WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
       WININET.dll!Connect - C:\Windows\syswow64\WININET.dll:0x13ec3
       WININET.dll!OpenConnection_Fsm - C:\Windows\syswow64\WININET.dll:0x55743
       WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7ce06
       WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
       WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
       WININET.dll!MakeConnection_Fsm - C:\Windows\syswow64\WININET.dll:0x7cd7d
       WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7cc8f
       WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
       WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
       WININET.dll!SendRequest_Fsm - C:\Windows\syswow64\WININET.dll:0x7c994
       WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7c848
       WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
       WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
       WININET.dll!HttpSendRequest_Start - C:\Windows\syswow64\WININET.dll:0x7d59e
       WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7bae4
       WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
       WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
       WININET.dll!HttpWrapSendRequest - C:\Windows\syswow64\WININET.dll:0x13984
       WININET.dll!InternalHttpSendRequestA - C:\Windows\syswow64\WININET.dll:0x97320
       WININET.dll!HttpSendRequestA - C:\Windows\syswow64\WININET.dll:0x99bb7

My function prototype is post(const Buffer &data, const string &object_name, const DWORD flags, const char** accept_types) so of all the parameters to the HttpSendRequest function, only the request_handle is allocated inside post(). That is done using the HttpOpenRequest() function and and InternetCloseHandle() at the end of the function is used to free it. I should also mention that the NULL & 0 parameters are allowed as valid inputs to the function according to the documentation (simply means no extra headers being sent).

So if this is not a false positive, I have no idea where the memory leak might be: it can't be my custom "data" object because post() doesn't own it (const &) so it does not match the allocation site.

BTW, I also checked the compilation setting so it matches the manual: debug mode with symbols, /MDd, etc...: that does not cut down on the number of false (?) positives in my case...

On another note, it would be helpful if the Inspector could be clearer sometimes as to which variable it's complaining about. If you have multiple arguments to a function, you can't always tell which one you should be looking into.

7 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Maybe you can use option "-knob detect-resource-leaks=false" to disable of reports from detecting all objects of Windows, which are in low level modules and hard to know...does it help? 

Hi Peter,

I am not using the command line so I assume what you suggest is the same as un-checking the Detect Resource Leaks box in the Visual Studio interface ?

Doing that cuts down on the number of errors detected but the one in question is still there:

P8: Error: Memory leak
 P8.75: Memory leak: 720 Bytes: New
(omitted)  Error X88: Allocation site: Function post: Module D:\Source\license system\Win32\Debug\license_test.exe
  Code snippet:
   128  
   129  again:
  >130      if (!HttpSendRequest(request_handle, NULL, 0, data, data.len()))
   131      {
   132          std::cout << "HTTP Request Status (POST): " << error() << std::endl;

  Stack (1 of 1 instance(s))
  >WININET.dll!CreateInstance - C:\Windows\syswow64\WININET.dll:0x14cb1
   WININET.dll!InitializeSocket - C:\Windows\syswow64\WININET.dll:0x14bd0
   WININET.dll!Connect_Start - C:\Windows\syswow64\WININET.dll:0x140bd
   WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x13ca4
   WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
   WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
   WININET.dll!Connect - C:\Windows\syswow64\WININET.dll:0x13ec3
   WININET.dll!OpenConnection_Fsm - C:\Windows\syswow64\WININET.dll:0x55743
   WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7ce06
   WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
   WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
   WININET.dll!MakeConnection_Fsm - C:\Windows\syswow64\WININET.dll:0x7cd7d
   WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7cc8f
   WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
   WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
   WININET.dll!SendRequest_Fsm - C:\Windows\syswow64\WININET.dll:0x7c994
   WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7c848
   WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
   WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
   WININET.dll!HttpSendRequest_Start - C:\Windows\syswow64\WININET.dll:0x7d59e
   WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7bae4
   WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
   WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
   WININET.dll!HttpWrapSendRequest - C:\Windows\syswow64\WININET.dll:0x13984
   WININET.dll!InternalHttpSendRequestA - C:\Windows\syswow64\WININET.dll:0x97320
   WININET.dll!HttpSendRequestA - C:\Windows\syswow64\WININET.dll:0x99bb7
   license_test.exe!post - d:\source\license system\license_lib\http.cpp:130

Other errors still also show up such as

P24: Error: Uninitialized memory access
 P24.9: Uninitialized memory access: New
(omitted) : Error X9: Read: Function HTTP: Module D:\Source\license system\Win32\Debug\license_test.exe
  Code snippet:
   29      HTTP::app_name = name;
   30      inet_handle = InternetOpen( name, INTERNET_OPEN_TYPE_PRECONFIG, 
  >31                                  NULL, NULL, 0 );
   32      if( inet_handle == NULL )
   33          throw HTTPException();

  Stack (1 of 1 instance(s))
  >iertutil.dll!_GetInHiveDefaultValue - C:\Windows\syswow64\iertutil.dll:0x8d3b2
   iertutil.dll!_GetDefaultValue - C:\Windows\syswow64\iertutil.dll:0xb39a7
   iertutil.dll!GetValue - C:\Windows\syswow64\iertutil.dll:0xb39cf
   iertutil.dll!GetDWORD - C:\Windows\syswow64\iertutil.dll:0x10bc0
   iertutil.dll!_IEConfiguation_InitializeHelper - C:\Windows\syswow64\iertutil.dll:0xc6195
   iertutil.dll!`dynamic atexit destructor for 'module'' - C:\Windows\syswow64\iertutil.dll:0x1b80ae
   iertutil.dll!IEConfiguration_GetBool - C:\Windows\syswow64\iertutil.dll:0x24c2
   WININET.dll!IEConfiguration_GetBool - C:\Windows\syswow64\WININET.dll:0x6de5c
   WININET.dll!`string' - C:\Windows\syswow64\WININET.dll:0xb80b0
   WININET.dll!Initialize - C:\Windows\syswow64\WININET.dll:0x8cdfb
   WININET.dll!CreateInstance - C:\Windows\syswow64\WININET.dll:0x8da93
   WININET.dll!CreateProxyManagerResolverInstance - C:\Windows\syswow64\WININET.dll:0x8d9dc
   WININET.dll!GlobalDataInitialize - C:\Windows\syswow64\WININET.dll:0x8a464
   WININET.dll!InternetOpenA - C:\Windows\syswow64\WININET.dll:0x979f3
   license_test.exe!HTTP - d:\source\license system\license_lib\http.cpp:31

Again, the only argument passed to the HTTP object's constructor is a const char*, which in this case is simply a hard-coded string in the caller function: no possible way this is uninitialized. Here again, the NULLs are allowed by the API: they mean the proxy info is not being passed to the function and should instead be read from the registry. And since the code is not throwing exceptions, I know the handle is being set properly; not using a proxy on my machine anyway.

I should also add that the Memory leak from line 130 also matches a uninitialized memory access report:

  Stack (1 of 1 instance(s))
  >WININET.dll!FindHeader - C:\Windows\syswow64\WININET.dll:0x79235
   WININET.dll!GetCacheTimeStampsFromHeaders - C:\Windows\syswow64\WININET.dll:0x85ad7
   WININET.dll!GetFromCachePostNetIO - C:\Windows\syswow64\WININET.dll:0x85bb4
   WININET.dll!HttpSendRequest_Start - C:\Windows\syswow64\WININET.dll:0x7bca9
   WININET.dll!RunSM - C:\Windows\syswow64\WININET.dll:0x7bae4
   WININET.dll!Run - C:\Windows\syswow64\WININET.dll:0x7b8dc
   WININET.dll!DoFsm - C:\Windows\syswow64\WININET.dll:0x7bfce
   WININET.dll!HttpWrapSendRequest - C:\Windows\syswow64\WININET.dll:0x13984
   WININET.dll!InternalHttpSendRequestA - C:\Windows\syswow64\WININET.dll:0x97320
   WININET.dll!HttpSendRequestA - C:\Windows\syswow64\WININET.dll:0x99bb7
   license_test.exe!post - d:\source\license system\license_lib\http.cpp:130

From this, I would guess it is complaining about the headers being sent but the API for HTTPSendRequest is clear on this point: you are allowed not to send extra headers.

I have escalated this problem to our engineering team, will get back as soon as I can.

It's better that you can attach compressed result directory, for investigating. Thank you, 

As requested, the zipped folder of the Inspector results; I turned back on the resource leak detection. I am unfortunately not able to share the source code of this for proprietary reasons. If you need source to reproduce the problem, I would have to set up an entirely new project and limit it to the HTTP section.

As I said before, it would be nice to simply know if this is a false positive or not; there's no way for me to know if the windows DLL are doing something that the Inspector is flagging as unsafe or if it's my fault in not calling the API functions properly.

Anlagen: 

Thanks for your result, let's wait for our developer's solution and/or know if need extra info with your helps.

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen