Real typed properties cause GPF in COMPLIB.DCL

Description

; checked by Anders Melander

Adding a published property that is based on a variable of type Real causes Delphi to GPF. To illustrate the problem, install this example component and add it to a form:

unit RealBug;

interface

uses WinTypes, WinProcs, Classes, Controls, Forms;

type
  TRealBug = class(TWinControl)
  private
    FVersion: Real;
  published
    Version: Real read FVersion write FVersion;
  end;

procedure Register;

implementation

  procedure Register;
  begin
    RegisterComponents('Bugs', [TRealBug]);
  end;

end.

Solution / workaround

From the Language Reference manual:

"Furthermore, the type of a property defined in a published section must be an ordinal type, a real type (Single, Double, Extended, or Comp, but not Real), a string type, a small set type, a class type, or a method pointer type."

The solution is to use Single, Double, Extended, or Comp, whichever is most appropriate to your data. It would have been better for the compiler to generate an error when attempting to publish a Real typed property.

Internal Error R398

Description

Reported by Heinz Höfling; checked by Steve Trefethen (Delphi Q&A)

When I Start Delphi 3.02, after ca. 5 Sec. I get an Error-Message "Fatal Error E:\projekt1.dpr(10): Internal Error: R398"

Solution / workaround

By Steve Trefethen:
Check to see if you have Detailed Map files turned on. In the IDE it's Project | Options | Linker | Map File | Detailed. In the command-line compiler it's -GD. If so turn it off and the error should go away. We are aware of this problem.

The compiler crashes on certain illegal language constructs

Description

Reported by Stefan Hoffmeister

When trying to compile code like

procedure CrashMe;
var
 x: extended;
begin
  x := Math.Math.IntPower(1, 2);
  { this obviously is wrong syntax 
    this does not depend on using the Math unit } 
end;

the Delphi 2.01 *compiler* itself throws an access violation and Delphi becomes very unstable. After such a crash it is strongly recommended to *immediately* restart Delphi.

Having an include file include itself hangs Delphi.

Description

Reported by Hallvard Vassbotn; checked by Rune Moberg

Jarle Stabell made me aware of a bug in the Delphi 2.0 and Delphi 3.0 compilers (Delphi 1.0 and BP7 handle this properly) related to use of recursive include files.
For instance, given a simple one-line include file called CIRCLE.INC:

{$I CIRCLE.INC}

Note that the include file includes itself. Now include this file in any unit in the project, for instance:

unit Unit1;
{$I CIRCLE.INC}
...
end.

Delphi will now hang while compiling and it will use a lot of CPU time. It is impossible to Cancel the compile and I have to force it down with a Kill task command (at least on my machine).

Note that this construct is not logical or perhaps even "legal", but in no circumstances should such a mistake hang the program. In BP7 and Delphi 1.0 the programmer is given a (somewhat confusing) error message instead.

Comment from Rune Moberg (12 Jul 98):
This has been fixed in Delphi 4; the message window now reads: "[Fatal Error] file1.txt(1): Recursive include file file1.txt"

Internal error on asm code with assignment to 'Result'

Description

Reported by Paul Heinz

This code fragment causes an Internal error C3254 when compiled in both Delphi 2.0 and 2.01. It compiles fine in Delphi 1.02:

function Fails(value: Extended): Extended;
begin
  asm
    FLD  value
    FSTP @Result
  end;
end; <--- Internal error C3254

Solution / workaround

This code fragment works around the problem.

function Works(value: Extended): Extended;
var
  res: Extended;
begin
  asm
    FLD  value
    FSTP res
  end;
  Result := res;
end;

Internal error C750 on code involving function results of type Object

Description

Reported by Hovik Melikian; checked by Anders Melander

After visiting your site, I tried to remember the situation when functions returning old-style objects are actually returning something strange but not the object. I COULDN'T REMEMBER, but found another bug:

type
  TBase = object
    Color: Integer;
  end;
  PBase = ^TBase;
  TPoint = object(TBase)
    X: Integer;
    Y: Integer;
  end;
  PPoint = ^TPoint;

var
  APoint: TPoint;

function GetAPoint: TBase;
begin
  Result := APoint;
end;

Here the compiler reports an "internal error C750".
But I'm sure there was another dangerous bug, when the compiler says nothing and does... crash your program.

Solution / workaround

Workaround: do not use objects? Sometimes I use them in Delphi when I want to control storage allocation myself and feel comfortable. Classes are always pointers and they can not 100% substitute old-style objects...

There's a problem with typed constants and / or conditional defines.

Description

Reported by Lars Fosdal

The problem arose when I was porting some code of mine from Delphi 1.02 to 2.01. Delphi crashes (or rather gives an Application Error) in both the D2 IDE and DCC32.EXE.
I've cleaned out the source as much as possible, while retaining the bug:
Source in .DPR form
Source in unit form
The problem seems to be with typed constants, but is interlinked with conditional defines in some strange way. In other words; the compiler seems to end up in a strange state which causes it to crash...
Does that sound familiar, or what? :)
There are several strange things about this code:

1. If you compile it in BP DOS mode/or DPMI mode, it compiles OK
2. If you compile it in Delphi 1.03, it compiles OK
3. If you remove the TestArrayBug declaration, it compiles OK
4. If you remove the first function, it compiles OK
5. If you remove ANY of the DEFINEs, it compiles OK
6. If you move the CONSTs to the first procedure, it compiles OK

The IDE gave me a dialog with the caption "Error": Access violation at address 0083FDC7. Read of address 00000003.
The commandline compiler gave me a dialog "DCC32.EXE - Application Error": The instruction at "0x00438ba7" referenced memory at "0x00000003".The memory could not be "read".
Another issue is that while the IDE seems to cope with the App.Error, it really is in a strange state. The editor suddenly becomes read-only for some of your project files. In the original source, if you did a change, and tried to save it, you'd get a "couldn't save" fault, just as if the previous source file was locked in some way. If you, in the IDE, try to compile it again, you get: C:\SRC\IFDEFBUG.PAS(1): Program or unit recursively uses it self.
I'm lost... Weird, ain't it?

Another reproducible compiler crash (access violation)

Description

Reported by Mark Bracey; checked by Stefan Hoffmeister

Compiling the following project will result in an access violation of the compiler: Project1.dpr, Unit1.pas, Unit1.dfm, Unit2.pas, Unit3.pas.
It probably has something to do with the two type declarations of TUnary, but what exactly causes it has not (yet?) been investigated.

Internal error L1086 caused by type declaration

Description

Reported by Hallvard Vassbotn; checked by Rune Moberg

I was notified of this as a D2 bug by Arsène von Wyss (avonwyss@beaulieu-software.ch). He said:

>type
>  TInternalError=type TObject;
>
>In Delphi 2.0, I get an internal error URW337. I tried to report this to
>Borland but nobody wanted to hear me...

I confirmed that I get the same error in D2. I made the following simple form to test it out in D3:

unit TypeBugU;
interface
uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;
type
  TForm1 = class(TForm)
  end;
  TInternalError = type TObject;  { << This is the only line I added }
var
  Form1: TForm1;
implementation
{$R *.DFM}
end.

The first attempt to compile this gives:
"Fatal Error: (0): Internal error: L1086."
On subsequent compilations I get:
"Fatal Error: ...: Unit SysUtils was compiled with a different version of System"}

Solution / workaround

Have to close down the project to reset Delphi so that it no longer believes I have a modified version of System.

Another URW376 compiler error, when declaring a Const MaxDim = High(Cardinal). Besides Cardinal, this happens with other ordinal types as well.

Description

Reported by Sverre A.C. Kittelsen; confirmed by Mårten Larsson and Lukas Masser

When declaring the constant

  Const MaxDim = High(Cardinal);

  Const MinDim = Low(Cardinal);

If one continues to try different recompiles, one periodically gets the error: Access violation at address 0080D233 in module 'DCC.DLL'. Read of address FFFFFFFF.

This is found using Delphi Professional 3.0 (Build 5.53), both with the IDE compiler and the command-line compiler. The machine was a Toshiba 730CDT with 48MB ram running Windows95.

Additional comment by Lukas Masser: I discovered that the Low(Cardinal) bug (Another compiler error URW376) isn't just linked to Cardinal but rather to sub types of any ordinal type (which Cardinal is).
An example:

unit LowHighBug;

interface

type  
  TBaseType       = (btValue0, btValue1, btValue2, btValue3, btValue4, btValue5);

  TSubType1       = Low(TBaseType)..High(TBaseType);
  TSubType2       = btValue1..btValue5;

const 
  LowSubType1     = Low(TSubType1);      // No error here, since it's the base type
//LowSubType2   = Low(TSubType2);      // Uncomment this
//HighSubType2  = High(TSubType2);     // or this to produce bug

implementation

end.

Another URW376 compiler error, when compiling packages.

Description

Reported by Stefan Hoffmeister and Chris Rankin; checked by Erik Berry

The following code demonstrates the problem for Delphi 3 (5.53):

{$A+,B-,C+,G+,H+,I+,J+,M-,O+,P+,Q+,R+,T-,U-,V+,W-,X+,Z1}
unit smapi;

{$D-,L-,Y+}
interface
implementation

const
  DLLName32 = 'mapi32';

end.


package email3;
{$R *.RES}
{$ALIGN ON}
{$ASSERTIONS ON}
{$BOOLEVAL OFF}
{$DEBUGINFO OFF}
{$EXTENDEDSYNTAX ON}
{$IMPORTEDDATA ON}
{$IOCHECKS ON}
{$LOCALSYMBOLS ON}
{$LONGSTRINGS ON}
{$OPENSTRINGS ON}
{$OPTIMIZATION ON}
{$OVERFLOWCHECKS OFF}
{$RANGECHECKS OFF}
{$REFERENCEINFO ON}
{$SAFEDIVIDE OFF}
{$STACKFRAMES OFF}
{$TYPEDADDRESS OFF}
{$VARSTRINGCHECKS ON}
{$WRITEABLECONST ON}
{$MINENUMSIZE 1}
{$IMAGEBASE $00400000}
{$DESCRIPTION 'TEmail - MAPI component'}
{$DESIGNONLY}
{$IMPLICITBUILD ON}

requires
vcl30;

contains
Smapi;

end.

Steps to produce the problem:

1. Copy both files to a Delphi path directory
2. File | Open "EMAIL3.DPK"
3. Click "Compile" or "Install"

---> Internal Error URW376.

This problem seems to depend on a few things (in SMAPI.PAS):
a) Local symbols must be turned OFF {$L-}
b) Symbol reference information must be turned ON {$Y+}
c) There must be a local symbol
d) It must be compiled as a package
e) SMAPI.PAS actually needs to be compiled [i.e. the DCU file is not up to date]

Solution / workaround

As stated above, the problem only seems to appears when Delphi needs to compile SMAPI.pas to SMAPI.dcu. Having said that, Delphi does seem to compile both the unit and the package successfully before throwing the URW376 error. Therefore you can work around the problem by restarting Delphi and then recompiling or reinstalling the package. The restart is necessary as the URW376 seems to corrupt Delphi somehow. Trying to reinstall the package without restarting will produce an access violation at address 0080D22B in module DCC.DLL
Of course, since this bug depends on the compiler options {$L-,Y+}, you could also work around by using {$L+,Y+} if you need symbol information and {$L-,Y-} if you don't.

Compile-Run sequence interrupted by Fatal Error: Internal Error L737

Description

Reported by Reinier Sterkenburg

It happens (spuriously) when the Run command is given while the source is modified, so a Compile (Make) is issued first. It looks like this is the same bug as in Delphi 3 where the error code is L1317. The L probably signifies 'Linker' because it happens after a succesful compile (compiler progress window disappears without indicating errors).
The bug is not very severe, although it can be quite annoying, when you are waiting for your program to start running when suddenly you realise this takes too long and something must be wrong.

Solution / workaround

A real solution is not known, but doing a "Build All" in stead of a "Run" or "Make" usually results in successful generation of the executable after which the program can be run.

Internal error C1655 on a piece of code that should compile.

Description

Reported by Eivind Bakkestuen; checked by Reinier Sterkenburg

The lines below will result in an "Internal error C1655", with the cursor positioned at the "End;" of the last procedure.
Insert the code below into the implementation section of unit1 after doing a 'new application' from the menu. Try compiling; the internal error occurs, both in the IDE and with DCC32.

Note: A "Syntax check" has no problem with this code: no hints, warnings or errors. So there's probably a problem with code generation.

var
  WinArbeidsPapir : Boolean;

Function Plukktall(Lin:String):double;
Begin
  Result := 0;
End;

Procedure WindowsArbeidsPapir(Lin:String);
Begin
  WinArbeidsPapir:=Boolean(Round(Plukktall(Lin)));
End;

Using the old object model, the destructor can not have parameters in Delphi 4.00. In Delphi 3 this was possible.

Description

Reported by Odd Dahm Sælen; checked by Reinier Sterkenburg

To reproduce the bug, include the attached unit in any project.
If all utilities that analyse the code are turned off, the IDE shows this message:

Access violation at address 0083146 in module DCC40.DLL

The compilation halts.
If these utilities are turned on, this message box shows nearly at once opening the project containing the offending module.

Internal errors SY1703 (in Delphi 3) and SY2149 (in Delphi 4)

Description

Reported by Vladimir Merzliakov; checked by Reinier Sterkenburg

To reproduce:
Attach the following unit to any project and compile.

unit BugUnit;

interface

type
  TClass1 = object
  protected
    function Func1 : integer;
    property Prop1 : integer read Func1;
  end;

  TClass2 = object(TClass1)
  public
    property Prop1;
  end;

  TClass3 = object(TClass1)
  public
    property Prop1 : integer read Func1;
  end;

function Main : integer;

implementation

function TClass1.Func1;
begin
  Result:=1;
end;

function Main : integer;
var C2 : TClass2;
    C3 : TClass3;
begin
  Result:=C3.Prop1; // no crash

  Result:=C2.Prop1; // Compiler crash with SY2149 internal error
end;

end.

The characteristics are:

1. If an old object model type (TClass1) has a protected property (Prop1)
2. and Prop1 has a read method
3. and a descendant of TClass1 (TClass2) changes the visibility of Prop1 to public
4. and variable (O1) has type TClass2

then the compiler CRASHES with SY2149 error code on expression O1.Prop1

Solution / workaround

Do not use visibility change of properties in old object model types. Redefine the property in descendant, instead.

A library exporting a subroutine with a name equal to itself makes causes an Access Violation in the compiler

Description

Reported by Sergey Mishkovskiy; checked by Reinier Sterkenburg

To reproduce:
Create a dpr file as follows:

library Test;

uses
  SysUtils,
  Classes;

procedure Test; stdcall; export;
begin
end;

exports
  Test;

begin
end.

When I try to build it, I get "Access violation at address 0081BE75 in module 'dcc40.dll'. Read of address 00000000." My guess is that compiler gets confused about identical project and export procedure name. If I change export name to something else it all compiles just fine.

Internal error C3973 (D4); C4273 (D3); C3690 (D2).

Description

Reported by Louis L.J.Wang; checked by Reinier Sterkenburg

The following simple project generates "Internal error C3973" while compiling with Delphi 4 Update Pack 2 (Build 5.104).
In Delphi 3.02 the error is C4273.
In Delphi 2.01 the error is C3690.

The error seems to occur when the compiler attempts to store the low-order three bytes out of a double word function result. Since the function returns the result in EAX, there is no simple instruction to store the low-order three bytes to a variable. This error does not occur if the source is a variable since Delphi can generate memory move instructions.

program Project1;

type
  T3Bytes = packed array[0..2] of Byte;
  T4BytesRecord = record
    case Integer of
      0: (V0: Integer);
      1: (V1: T3Bytes);
  end;

function Null4BytesRecord: T4BytesRecord;
begin
  Result.V0 := 0;
end;

procedure FailProc;
var
  V: T3Bytes;
begin
  V := Null4BytesRecord.V1;
end;  // Internal error C3973 here.

// This procedure works fine.
//
// procedure FailProc;
// var
//   V: T3Bytes;
//   T: T4BytesRecord;
// begin
//   T := Null4BytesRecord;
//   V := T.V1;
// end;

begin
  FailProc;
end.

Solution / workaround

Assign the result to a temporary variable and then move from the temporary variable to the destination (see the part that has been commented out in the source code above).