> 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): > > 1. 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. > > 2. 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? > > 3. 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
