> Which requests are you referring to? Please be more specific. Since you
> obviously can track the "leaks", where EXACTLY are they occuring?
The tool I'm using to track allocation is AutomatedQA.
Here's the call stack information it is providing:
Routine Name Source File Source Line
========================================
InitInstance.....................system.pas...................8422
NewInstance..................system.pas...................8368
ClassCreate...................system.pas....................9027
Create...........................SyncObjs.pas................194
LoadOpenSLLibrary.....IdSSLOpenSSL.pas......443
Create...........................IdSSLOpenSSL.pas......939
Init................................IdSSLOpenSSL.pas.......817
ConnectClient................IdSSLOpenSSL.pas......733
Connect........................IdTCPClient.pas.............73
ThreadDoConnect........Search.pas......................1796
ThreadSabreConnect....Search.pas......................2054
ExecuteTask.................Search.pas.....................625
Execute........................Search.pas......................484
ThreadProc..................classes.pas.....................9372
ThreadWrapper............system.pas.....................11562
StartLib........................system.pas.....................11014
InitLib..........................SysInit.pas......................575
When the .Connect fails, the error returned is:
"Access violation at address 00000000. Write of address 00000000"
Is this error normal for the .Connect method call?
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:446e212b@newsgroups.borland.com...
>
> "Larry" <lchiasson@autoeurope.com> wrote in message
> news:446e109c@newsgroups.borland.com...
>
>> After each request is fullfilled, allocated critical sections
>> are not destroyed, sometimes, not all the time.
>
> Which requests are you referring to? Please be more specific. Since you
> obviously can track the "leaks", where EXACTLY are they occuring?
>
>> Also, the number of orphaned critical sections would vary (3, 4, 7,
>> etc.).
>
> Any Indy objects that create their own provate critical sections always
> make
> sure to free them properly. The only "leaks" are in the 2 global critical
> section objects that Indy can't free without causing crashes during unit
> finalizations.
>
>> Also, if the .Connect method call fails, how should be handled?
>> Our current method of handling is to completely start over
>> (release the allocated resources and call the function again)
>> Or is it safe to just make the call again?
>
> Yes, you can just make the call again.
>
>> Since we currently the socket resources in the thread, I wonder
>> if creating in the main thread would solve the orphaned CS mystery.
>
> No.
>
>
> Gambit
