Question

In searching for a highly intermittent memory corruption in a Delphi XE program, I have found a class constructor which initializes a few fields in the class, and then calls inherited. I believe the initializations were added after the constructor was first written, and accidentally in the wrong place. I have now corrected it to call inherited first. The exceptions from the memory corruption almost always occur in a method of this class.

Question: is it possible that this mistake caused an intermittent memory corruption? In tracing the code, it seems not, but I would really like this fix to be what solves the intermittent issue. That it does not occur for a while after fixing the problem will not prove that it has gone away.

Some code:

Tmyclass = class
  ctype : integer;
  ts : tstringlist;
  th : thandle;
public
  Constructor Create;
  Destructor Destroy; override;
  ...
end;

Constructor Tmyclass.Create;
begin
  ctype := 3;
  doinit;
  inherited;
end;

Answer 1

Here are typical steps of an object creation:

• Memory allocation of the object instance;
• Fill all memory with zero (to initialize all fields, especially string);
• Call all nested constructors, beginning with the latest child, letting inherited call every parent – that is why you shall write inherited in both constructors and destructors.

So, inherited calls the parent method – you can even specify a parent level, or call none if you are sure you can do that (but may break the SOLID principles).

In fact, when a constructor is called, there is an hidden parameter added to the method:

Constructors and destructors use the same calling conventions as other
methods, except that an additional Boolean flag parameter is passed to
indicate the context of the constructor or destructor call.

A value of False in the flag parameter of a constructor call indicates
that the constructor was invoked through an instance object or using
the inherited keyword. In this case, the constructor behaves like an
ordinary method. A value of True in the flag parameter of a
constructor call indicates that the constructor was invoked through a
class reference. In this case, the constructor creates an instance of
the class given by Self, and returns a reference to the newly created
object in EAX.

A value of False in the flag parameter of a destructor call indicates
that the destructor was invoked using the inherited keyword. In this
case, the destructor behaves like an ordinary method. A value of True
in the flag parameter of a destructor call indicates that the
destructor was invoked through an instance object. In this case, the
destructor deallocates the instance given by Self just before
returning.

The flag parameter behaves as if it were declared before all other
parameters. Under the register convention, it is passed in the DL
register. Under the pascal convention, it is pushed before all other
parameters. Under the cdecl, stdcall, and safecall conventions, it is
pushed just before the Self parameter.

Source: official Delphi documentation

So you can be sure that, wherever the inherited is called, it will be safely handled. For instance, initialization of fields (reset to 0) will be processed only once, before all constructors are called.

The TObject.Create default constructor (the one called in your inherited line) is just a begin end void block, which does nothing. It is not even necessary/mandatory to call inherited here, but it is a good habit, since if you change your object hierarchy, it may be needed afterall.

Only issue may be if some fields are set inside this inherited method (ctype := 2 e.g.), after having been set in the child – but this is not compiler’s fault, this is up to user code!