<HTML dir=ltr><HEAD>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY>
<P><FONT face=Arial size=2>Hi Dan et al.,</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>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):</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>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?</FONT></P>
<P>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.</P>
<P>So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated.</P>
<P>Thanks,</P>
<P>Misha</P>
<P>---</P>
<P>diff --git a/dlls/urlmon/tests/protocol.c b/dlls/urlmon/tests/protocol.c<BR>index 00335b3..5b3579b 100644<BR>--- a/dlls/urlmon/tests/protocol.c<BR>+++ b/dlls/urlmon/tests/protocol.c<BR>@@ -295,7 +295,9 @@ static HRESULT WINAPI ProtocolSink_Switch(IInternetProtocolSink *iface, PROTOCOL<BR> }</P>
<P> SET_EXPECT(ReportData);<BR>+ printf("!!! Continue %p -->\n", pProtocolData);<BR> hres = IInternetProtocol_Continue(http_protocol, pProtocolData);<BR>+ printf("!!! Continue <--\n");<BR> ok(hres == S_OK, "Continue failed: %08x\n", hres);<BR> CHECK_CALLED(ReportData);</P>
<P>@@ -1255,6 +1257,7 @@ static void test_http_protocol_url(LPCWSTR url, BOOL is_first)<BR> hres = IClassFactory_CreateInstance(factory, NULL, &IID_IInternetProtocol,<BR> (void**)&http_protocol);<BR> ok(hres == S_OK, "Could not get IInternetProtocol: %08x\n", hres);<BR>+ printf("!!! IInternetProtocol: %p %p\n", http_protocol, http_protocol+sizeof(IInternetProtocol));<BR> if(SUCCEEDED(hres)) {<BR> BYTE buf[3600];<BR> DWORD cb;<BR></P></BODY></HTML>