Hi Dan et al.,
So I just wanted to let you know that I have looked somewhat at one (the only as far as I saw) of the valgrind results related to HttpProtocol in urlmon, and basically it involves passing a pointer to a PROTOCOLDATA from a local variable inside a function to the ProtocolSink call which ends up sending a message with this pointer. When this pointer is processed later, since it is a pointer to a local variable which (presumably) exists only on the stack, it is not really valid.
Now this is quite easy to "fix" with a five-line patch that HeapAlloc's the proper structures. However, I was trying to figure out how native does this to copy it, and kind of ran into a dilemma. Namely, doing a simple patch like shown below (this probably won't really be a diff as I copy/pasted it into WebMail which will probably mess it up, but it should give a general idea) and then doing a WINEDLLOVERRIDES with native urlmon and wininet and +relay WINEDEBUG I can see that the the PROTOCOLDATA pointers are pointing to stuff like 0x7d7ad790 and 0x7d7ad820. Now, much to my suprise, these addresses, nor addresses in the proximate range (approximate) to that address don't seem to be part of any other relay calls, including any calls to any sort of allocation functions. Now this leaves me a little stumped ,as I can only see a few ways to properly implement these PROTOCOLDATA pointers (without a memory leak):
A static PROTOCOLDATA variable (local or global). In this case, the address I see for native should never change I believe, but also this would not be correct as potentially you could have more than one HttpProtocol using the same structure.
Dynamic allocation of the PROTOCOLDATA structure. This seems like the best option to me, but native either does not seem to be using it or allocates it in some way in which the address or even partial versions of the address does not appear in any allocation functions (or really anywhere) in the
+relay log. Any ideas on what allocation functions I could be missing here?
- Have one PROTOCOLDATA structure per IInternetProtocol implementation of http. This seems reasonable too, except I am also printing out the address of the IInternetProtocol structure and clearly PROTOCOLDATA is not in an address range anywhere near this structure, and it is never allocated so it
can't be a pointer within that structure.
So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated.
Thanks,
Misha
Hmm... so it looks like upon investigation the address ranges for PROTOCOLDATA with antive dlls are actually suspiciously similar to those I see in the current local variable implementation... which makes me think that the implementation is dissimilar (and thus leaky) in the downstream ProtocolSink implementation in binding.c, which will be a little harder to test...
Misha