It should not be related with my thread design. It gives no AVs or so.
THttpCli is supposed to be a component that runs in any thread/context. So
it is strange. Anyway, my fix solves the problem and I see no reason why
CtrlSocket cannot be destroyed after HWindowHandle.
Regards,
SZ
----- Original Message -----
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing" <twsocket@elists.org>
Sent: Sunday, February 05, 2006 2:15 PM
Subject: Re: [twsocket] Remember the SetWindowLong bug in WSocket?
> Fastream Technologies wrote:
>> Are
>> you using NOFORMS?
>
> YES.
>
>> As you may remember, I am using a main thread for listener and worker
>> threads for THttpConnection. THttpCli's are also in it.
>
> So it's most likely somthing with your thread design.
> Try to run my test, takes less that 5 minutes (incl.
> porting it to BCB)!
>
> Arno
>
>
>> This is a reverse
>> proxy.
>>
>> Regards,
>>
>> SZ
>>
>> ----- Original Message -----
>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>> To: "ICS support mailing" <twsocket@elists.org>
>> Sent: Sunday, February 05, 2006 1:41 PM
>> Subject: Re: [twsocket] Remember the SetWindowLong bug in WSocket?
>>
>>
>>> Fastream Technologies wrote:
>>>> I agree with you in your both emails BUT emprically it works in the way
>>>> I wrote. Try creating and destroying 1000 httpclients with NOFORMS and
>>>> you will see that you will be wasting more than 20MB of RAM!!
>>>
>>> I cannot reproduce that. What am I doing wrong?
>>> 20 MB should become visible in taskmanager, correct?
>>>
>>> Here my test:
>>> procedure TForm1.Button1Click(Sender: TObject);
>>> var
>>> L : TList;
>>> H : THttpcli;
>>> I : Integer;
>>> begin
>>> L := TList.Create;
>>> try
>>> for I := 1 to 1000 do
>>> begin
>>> H := THttpCli.Create(nil);
>>> L.Add(H);
>>> PostMessage(H.Handle, WM_USER + 1, 0, 0);
>>> end;
>>> Sleep(1000);
>>> for I := 0 to L.Count -1 do
>>> begin
>>> THttpCli(L[I]).Free;
>>> L[I] := nil;
>>> end;
>>> finally
>>> L.Free;
>>> L := nil;
>>> end;
>>> end;
>>>
>>> Arno
>>>
>>>>
>>>> Regards,
>>>>
>>>> SZ
>>>>
>>>> ----- Original Message -----
>>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>>> To: "ICS support mailing" <twsocket@elists.org>
>>>> Sent: Saturday, February 04, 2006 5:38 PM
>>>> Subject: Re: [twsocket] Remember the SetWindowLong bug in WSocket?
>>>>
>>>>
>>>>> BTW: Also this returns TRUE for both windows:
>>>>>
>>>>> function XSocketDeallocateHWnd(Wnd: HWND): boolean;
>>>>> begin
>>>>> Result := (SetWindowLong(Wnd, 0, 0) <> 0) and DestroyWindow(Wnd);
>>>>> end;
>>>>>
>>>>>
>>>>> Arno Garrels wrote:
>>>>>> Fastream Technologies wrote:
>>>>>>> I found the ICS bug: when I put the below in the ThttpCli
>>>>>>> descendent's destructor, it works:
>>>>>>>
>>>>>>> SetWindowLong(FWindowHandle, 0, 0);
>>>>>>> DestroyWindow(FWindowHandle);
>>>>>>> SetWindowLong(FCtrlSocket->Handle, 0, 0);
>>>>>>> DestroyWindow(FCtrlSocket->Handle);
>>>>>>>
>>>>>>> In THttpCli destructor, the destruction order of the CTrlSocket is
>>>>>>> first so I think that's why it leaks the window. And no,
>>>>>>> CodeGuard/Memproof/Eurekalog cannot show undeleted windows.
>>>>>>
>>>>>> In WSocket.pas, XSocketDeallocateHWnd, there should be a call to
>>>>>> SetWindowLong().
>>>>>>
>>>>>> function XSocketDeallocateHWnd(Wnd: HWND): boolean;
>>>>>> begin
>>>>>> SetWindowLong(Wnd, 0, 0); { Clear the object reference }
>>>>>> Result := DestroyWindow(Wnd);
>>>>>> end;
>>>>>>
>>>>>> If not, make sure that you have latest ICS-Beta installed (not
>>>>>> sure if it is in the release). I've my doubts that order of
>>>>>> destroying the windows matters, but not 100% sure.
>>>>>>
>>>>>> ---
>>>>>> Arno Garrels [TeamICS]
>>>>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>>>>
>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> SZ
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Arno Garrels" <[EMAIL PROTECTED]>
>>>>>>> To: "ICS support mailing" <twsocket@elists.org>
>>>>>>> Sent: Saturday, February 04, 2006 1:28 PM
>>>>>>> Subject: Re: [twsocket] Remember the SetWindowLong bug in WSocket?
>>>>>>>
>>>>>>>
>>>>>>>> Fastream Technologies wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> That bug caused a lot of frustration here. Now the problem is
>>>>>>>>> resolved for
>>>>>>>>> FTP and web servers with my fix BUT for the reverse proxy, there
>>>>>>>>> is
>>>>>>>>> a
>>>>>>>>> window leakage that cannot be detected by CodeGuard. It seems the
>>>>>>>>> problem is in THttpCli destructor. XWindowDealloc returns true but
>>>>>>>>> I have BIG doubts. It is a bit confusing because in THttpCli there
>>>>>>>>> are two handles and two windows! One is for the THttpCli and the
>>>>>>>>> other one is for THttpCli->CtrlSocket. Could someone take a look?
>>>>>>>>> It leaks 40KB per socket!!!
>>>>>>>>
>>>>>>>> Have you cross-checked one of the THttpCli demo projects?
>>>>>>>> Here MemProof says "No leak found" (beside 1x 4k in
>>>>>>>> MakeObjectInstance
>>>>>>>> which
>>>>>>>> is normal..).
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Arno Garrels [TeamICS]
>>>>>>>> http://www.overbyte.be/eng/overbyte/teamics.html
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> SZ
>>>>>>>> --
>>>>>>>> To unsubscribe or change your settings for TWSocket mailing list
>>>>>>>> please goto http://www.elists.org/mailman/listinfo/twsocket
>>>>>>>> Visit our website at http://www.overbyte.be
>>>>> --
>>>>> To unsubscribe or change your settings for TWSocket mailing list
>>>>> please goto http://www.elists.org/mailman/listinfo/twsocket
>>>>> Visit our website at http://www.overbyte.be
>>> --
>>> To unsubscribe or change your settings for TWSocket mailing list
>>> please goto http://www.elists.org/mailman/listinfo/twsocket
>>> Visit our website at http://www.overbyte.be
> --
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
