Gambit,
Ignore the Access violation question as I found the cause:
Allocation profiling with AutomatedQA.
When I don't profile, no error.
I apologize for any confusion, etc. I may have caused.
"Larry" <lchiasson@autoeurope.com> wrote in message
news:446e28c5$1@newsgroups.borland.com...
>> 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
