- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your result, let's wait for our developer's solution and/or know if need extra info with your helps.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page