EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Weird interaction

Posted: 09/18/2012 18:59:40
by Ciaran Costelloe (Standard support level)
Joined: 07/10/2009
Posts: 26

I don't know if this is a bug with SBB, Indy or CodeGear. I don't even know that I can call it a bug at all, because it happens when I hooked up a TIdLogFile to a TElClientIndySSLIOHandlerSocket's Intercept, which it possibly was not designed for. Anyway, I decided I should tell you because the result of this can be very weird and totally unexpected for me.

Using CodeGear RAD Studio 2007, fully patched, with a very recent Indy 10 and very recent TElClientIndySSLIOHandlerSocket.

I created a new project, dropped a TElClientIndySSLIOHandlerSocket, Indy's TIdLogFile and Indy's TIdIMAP4 on a form and hooked them up, and wrote a relatively simple program to test against an IMAP server. Generally works fine until I found a bug in TIdIMAP4's InternalRetrievePart, but the bug is a different story for Indy.

If I set the TIdLogFile's Filename to a valid file and its Active to True (on the design-time properties) it works fine, until you close the project, when the following exception is thrown:

Assertion failure (C:\MyProgs\Delphi\IndyImap\Source\Indy10CodeGear\Lib\System\IdStreamVCL.pas, line 91)

Next I get the following exception:

Access violation at address 2000679C in module 'rtl100.bpl'. Read of address FFFFFFFD.

By the way, line 91 in IdStreamVCL.pas is:


CodeGear then is totally unstable: strange Access Violation exceptions in good code, more exceptions if you shut down CodeGear followed by a Windows error followed by a strange window/form appearing on the screen.

This happens even if you just start CodeGear, open the project, and close it (no editing, compiling or anything). The problem goes away if you set TIdLogFile's Active to False.

Could TElClientIndySSLIOHandlerSocket's destructor be firing a notification/event at design-time?

Posted: 09/18/2012 23:34:56
by Eugene Mayevski (Team)

TElClientIndySSLIOHandlerSocket has just one line in destructor - FreeAndNil(FSecureClient) which you can easily comment out if you suspect it can cause a problem . But it hardly can - FreeAndNil won't do anything if FSecureClient is nil.

Also there's no unit finalization code present in SBIndyIOHandler10.pas.

In general everything looks like you have memory corruption here but it doesn't seem to be related to SBIndyIOHandler10, but by Indy itself.

Sincerely yours
Eugene Mayevski
Posted: 09/19/2012 13:57:10
by Ciaran Costelloe (Standard support level)
Joined: 07/10/2009
Posts: 26

Hi Eugene.

Thanks, if I find out anything more I will let you know.

Posted: 09/19/2012 16:52:58
by Ciaran Costelloe (Standard support level)
Joined: 07/10/2009
Posts: 26

I put a breakpoint in IdLogFile which got executed when you closed the project in the IDE, and this is the call stack:

IdLogFile.TIdLogFile.LogWriteString('Stat Disconnected.'#$D#$A)
:00426176 TComponent.DestroyComponents + $4A

OK, what I think is happening is that when you close a project, the IDE destroys the design-time components, causing the IO Handler's Close to execute, which kicks in the IdLogFile to log the "disconnect", but since it is a design-time component, it won't have a working stream, so you get the exception:

Assertion failure (C:\MyProgs\Delphi\IndyImap\Source\Indy10CodeGear\Lib\System\IdStreamVCL.pas, line 91)

It is surprising how badly crippled CodeGear becomes after this. I am also surprised that the code gets called at all when a design-time component is destroyed, I never realised all this happened.

I will talk to Gambit about adding an "if not IsDesignTime then begin" or "if Assigned(FFileStream) then begin" in the right place(s) in TIdLogFile, but I have not thought about whether there is a wider issue that any design-time components may need to watch out for something here. I know I am guilty of calling Close in a destructor or in an Open without thinking of any side-effects!

Posted: 09/19/2012 23:39:21
by Eugene Mayevski (Team)

I think this is a clear bug of Indy (not checking presence of the object, if you don't always allocate it) so there's nothing blame yourself for.

Sincerely yours
Eugene Mayevski
Posted: 09/20/2012 17:00:23
by Ciaran Costelloe (Standard support level)
Joined: 07/10/2009
Posts: 26

Gambit is checking in changes to TIdLogFile, which should appear in the Indy snapshot in the next 24 hours.





Topic viewed 1723 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!