Jump to content

Exception in TCustomSmtpClient.Destroy;

Recommended Posts



When running a software of mine in ReactOS i'm getting rare Delphi exception "Delphi Exception at address: 0049F658". Using IDR I identified that this corresponds to TCustomSmtpClient.Destroy;

Looking at the code i'm surprised to see that the "safe destroy" pattern is used for FHdrLines and FAuthTypesSupported but NOT for FMailMessage and FRcptName, while all 4 of them are TStrings created in the constructor.

if Assigned(FHdrLines) then begin
        FHdrLines := nil;

    if Assigned(FAuthTypesSupported) then begin
        FAuthTypesSupported := nil;


I would have simply expected


(or FreeAndNil(variable) )

Is it intentionnal ?


same in 





Similar issue with TFormDataAnalyser.PartSaveDataToFile, TFormDataItem.SaveToFile, TIcsFtpMulti.IntDownOne, OverbyteIcsFtpMultiW, OverbyteIcsFtpSrv, OverbyteIcsFtpSrvW where .Destroy is called while .Free would be expected

Same for OverbyteIcsFtpCli.pas (3 occurences of FModeZStream.Destroy; instead of FModeZStream.Free;)


... global check to be done.

Edited by Kyle_Katarn31

Share this post

Link to post

If that code is from a destructor it's bizarre. Just call Free on each instance variable. 


But that may not be the issue, it would only be an issue if there were stale references in one of those instance variables. 


The issue may be a double free of the object. Or something else. Debugging required. 

Edited by David Heffernan

Share this post

Link to post

Code comes from ICS TCustomSmtpClient.Destroy;

Compiled with D7

Not fully reproductible but there might be something rotten here.


anyway I agree that simply calling .free or FreeAndNil would be a wiser option here

Edited by Kyle_Katarn31

Share this post

Link to post

You should tell us which source code line EXACTLY is causing the exception.

madExcept could also help you find errors in code which doesn't immediately cause an exception.


Share this post

Link to post

Calling Destroy in destructor without having nil check first is definitely incorrect code that can lead to memory leaks as destructor needs to be able to handle partially constructed instances. That is why Free is commonly used as it does not require sprinkling destructors with nil checks before calling Destroy. 


But, very likely this bad code in the destructor is not the primary cause of the issues you are seeing and that there is more going on. If the destructor is at fault, then this means that the instance was not properly constructed and that construction raised an exception. Otherwise the core problem is in some other code we don't see here.

Share this post

Link to post
2 hours ago, Kyle_Katarn31 said:

Any clue or comment?

The error could be in code outside the destructor.  So look in that code. We cannot see it.

Share this post

Link to post

Exception :

(dll/win32/kernel32/client/except.c:735) Delphi Exception at address: 0049F658
(dll/win32/kernel32/client/except.c:736) Exception-Object: 009CB4C4
(dll/win32/kernel32/client/except.c:737) Exception text: 955cb0

MAP file :

049F09C:{OverbyteIcsSmtpProt}constructor TCustomSmtpClient.Create(AOwner:TComponent);
049F2F8:{OverbyteIcsSmtpProt}destructor TCustomSmtpClient.Destroy;
049F398:{OverbyteIcsSmtpProt}procedure sub_0049F398(?:?; ?:?);
049F400:{OverbyteIcsSmtpProt}procedure sub_0049F400;
049F410:{OverbyteIcsSmtpProt}procedure sub_0049F410;
049F44C:{OverbyteIcsSmtpProt}procedure sub_0049F44C;
049F488:{OverbyteIcsSmtpProt}procedure sub_0049F488(?:?);
049F51C:{OverbyteIcsSmtpProt}procedure sub_0049F51C(?:?);
049F5A8:{OverbyteIcsSmtpProt}procedure sub_0049F5A8(?:?);
049F5D0:{OverbyteIcsSmtpProt}function sub_0049F5D0(?:?; ?:?):?;
049F634:{OverbyteIcsSmtpProt}procedure sub_0049F634(?:TCustomSmtpClient);
049F680:{OverbyteIcsSmtpProt}procedure sub_0049F680;
049F6A0:{OverbyteIcsSmtpProt}procedure sub_0049F6A0(?:?);
049F6C0:{OverbyteIcsSmtpProt}procedure sub_0049F6C0(?:?);
049F6E0:{OverbyteIcsSmtpProt}procedure sub_0049F6E0(?:?);
049F780:{OverbyteIcsSmtpProt}procedure sub_0049F780(?:TCustomSmtpClient; ?:?);
049F7A0:{OverbyteIcsSmtpProt}procedure sub_0049F7A0(?:?);
049F7FC:{OverbyteIcsSmtpProt}procedure sub_0049F7FC(?:?);
049FA30:{OverbyteIcsSmtpProt}procedure sub_0049FA30(?:?; ?:?);
049FE08:{OverbyteIcsSmtpProt}procedure sub_0049FE08(?:?);
049FED8:{OverbyteIcsSmtpProt}procedure sub_0049FED8(?:TCustomSmtpClient; ?:?; ?:AnsiString; ?:?; ?:?; ?:?; ?:?);


Share this post

Link to post

Nobody is going to be able to tell you what's wrong. You'll need to do some debugging. 


Does the issue occur when not using ReactOS? 

Share this post

Link to post
7 hours ago, Kyle_Katarn31 said:

No, never seen this but very often this kind of exception are "hidden" by Windows....

No they are not

Share this post

Link to post
11 hours ago, Kyle_Katarn31 said:

Not possible. Random exception while running for a long time in ReactOs (far from my IDE)

You can use Delphi Remote debugger. You probably can run ReactOS in a virtual machine hosted on your Windows computer.

I don't know ReactOS. It is not Windows and it is still at an early stage. You may be faced to incompatibilities between Windows and ReactOS. Did you try to run your program under Windows ?

  • Like 1

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now