Graza
Graza

Reputation: 5050

How to solve Delphi's [Pascal Fatal Error] F2084 Internal Error: LA33?

I'm really sick of this problem. Google searches always seem to suggest "delete all bpls for the package", "delete all dcus". Sometimes this just-does-not-work. Hopefully I can get some other ideas here.

I have a package written in-house, which had been installed without issue a few months ago. Having made a few changes to the source, I figured it was time to recompile/reinstall the package. Now I get two errors, the first if I choose "install" is

Access violation at address 02422108 in module 'dcc100.dll'. Read of address 00000000.

...or if I try to build/compile the package, I get

[Pascal Fatal Error] F2084 Internal Error: LA33

This is one of those Delphi problems that seems to occur time and time again for many of us. Would be great if we could collate a response something along the lines of "any one or combination of these steps might fix it, but if you do all these steps it will fix it...."

At the moment, I've removed all references to the bpl/dcp files for this package, but still getting the same error...

Using BDS2006 (Delphi)

Update 01-Oct-2008: I managed to solve this - see my post below. As I can't accept my own answer, I'm not entirely sure what to do here. Obviously these types of issues occur frequently for some people, so I'll leave it open for a while to get other suggestions. Then I guess if someone collates all the info into a super-post, I can accept the answer

Upvotes: 19

Views: 25614

Answers (13)

Ted Rybicki
Ted Rybicki

Reputation: 11

And now watch out of this in Delphi 11 can be hard to find when compiling a unit like this: type TFormMain = class( TForm )
public procedure otherProcedure; procedure badDynamic; end;

procedure TFormMain.otherProcedure; var i: integer; begin for i := 0 to 10 do; end;

procedure TFormMain.badDynamic; begin var noTypeInfo:= otherProcedure; <-- [dcc.. Fatal Error] end;

You can get a compiler message and it halts with no indication where the problem code is, here (258) is just the end or last line of the unit.

Target Platforms (Windows 32-bit): [dcc32 Fatal Error] main.pas(258): F2084 Internal Error: AV7A5C191D(7A5C000.. or Target Platforms (Windows 64-bit): [dcc64 Fatal Error] main.pas(258): F2084 Internal Error: URW2707

Upvotes: 0

Christian
Christian

Reputation: 11

I just experienced a similar behaviour, resulting in internal error LA30. The reason were newly added string constants. After changing from const cLogFileName : string = 'logfilename.log';

to const cLogFileName = 'logfilename.log';

(and of course restarting of Delphi IDE) the error was not showing up anymore.

Upvotes: 0

Ash
Ash

Reputation: 1

As my experience of Internal Error is that, I re-wrote line by line and compile again and realized that some if else statement does not work like

Internal Error Occurs

 if (DataType in ASet) 
    begin
 //do work
    end
    else if (DataType = B)
    begin
 //do work
    end
    else 
    begin
 //do work
    end;

How I solved :

if (DataType = B)
        begin
     //do work
        end
        else if (DataType in ASet) 
        begin
     //do work
        end
        else 
        begin
     //do work
        end;

Just switched the conditions as example.Hope it helps.

Upvotes: 0

TmTron
TmTron

Reputation: 19371

Delphi XE3 Update 2

F2084 Internal Error: URW1147

CASE 1:

problem was that a type was declared in a procedure of a generic class.

procedure TMyClass<TContainerItem, TTarget>.Foo();
type
  TCacheInfo = record
    UniqueList: TStringList;
    UniqueInfo: TUniqueInfo;
  end;
var
  CacheInfo: TCacheInfo;

moving the type declaration to the private part of the class declaration solved this issue.

CASE 2:

problem in this case was related to an optional parameter:

unit A.pas;
interface
type
  TTest<T> = class
  public
    type
      TTestProc = procedure (X: T) of object;
    constructor Create(TestProc_: TTestProc = nil);
  end;
...

the internal compile error occurred as soon as a variable of the TTest class was declared in another unit: e.g.

unit B.pas:

uses A;
var
  Test: TTest<TObject>;

solution was to make the constructor argument of TestProc_ non-optional.

Upvotes: 1

SeeMoreGain
SeeMoreGain

Reputation: 1273

From the various answers this error looks to be a generic unhandled exception by the compiler.

My issue was caused by mistakenly calling function X(someString:String) : Boolean; which altered the string and returned a boolean, using someString := X(someString);

Upvotes: 0

user3310694
user3310694

Reputation: 11

Disabling "Include remote debug symbols" from the Linker Options fixed the issue for me Delphi 2007, dll project

Upvotes: 1

Marco
Marco

Reputation: 338

Try cleaning up the "Output Directory" so Delphi cannot fine dirty .DCUs and it is forced to bould the .PAS. Sometimes this helps. In case you didn't configure an "output directory", try deleting (or better moving in a backup folder) all the .DCU files.

Upvotes: 1

Riccardo Zorn
Riccardo Zorn

Reputation: 5615

For me, in D2010 disabling the compiler option "Emit runtime type information" did the trick.

Upvotes: 0

Pete
Pete

Reputation: 31

I wasted several hours on this issue, deleting dcu's, etc to no avail.

Finally, what worked for me was to uncheck Overflow Checking in Compiler Options, rebuilding the project, re-checking Overflow Checking, and rebuilding again. Voila! the problem has gone away. Go figure. (still using D7).

Upvotes: 3

Biz
Biz

Reputation: 31

Maybe the following step will be a better solution:
Declare the array as a type and just define the class constant with this type, eg.

TMyArray = array[TErrEnum] of string;

TMyClass = class(TComponent)
private
  const ErrStrs: TMyArray
    = ('', //erOK
       'Invalid user name or password', //erInvUserPass
       'Trial Period has Expired'); //erTrialExp
protected
  ...
public
  ...
end;

This makes the array declaration explicit.

Upvotes: 3

bjaastad_e
bjaastad_e

Reputation: 711

I had a similar case, where the solution was to remove the file urlmon.dcu from /lib/debug.

It also worked to turn off "use debug .dcus" altogether. This of course is not desirable, but you can use it to check whether the problem lies with any of your own units, or with any of delphi's units.

Upvotes: 1

Graza
Graza

Reputation: 5050

I managed to solve this, following the below procedure

  1. Create a new package
  2. One by one, add the components to the package, compile & install, until it failed.
  3. Investigate the unit causing the failure.

As it turns out, the unit in question had a class constant array, eg

TMyClass = class(TComponent)
private
  const ErrStrs: array[TErrEnum] of string
    = ('', //erOK
       'Invalid user name or password', //erInvUserPass
       'Trial Period has Expired'); //erTrialExp
protected
  ...
public
  ...
end;

So it appears that Delphi does not like class constants (or perhaps class constant arrays) in package components

Update: and yes, this has been reported to codegear

Upvotes: 16

Lars Truijens
Lars Truijens

Reputation: 43602

These are bugs in the compiler/linker. You can find many references of these bugs on the internet in different Delphi versions, but they are not always the same bugs. That makes it difficult to give one solution for all those different kind of problems.

General solutions that might fix it are, as you noted:

  • Remove *.dcp *.dcpil *.dcu *.dcuil *.bpl *.dll
  • Rewrite your code in another way
  • Tinker with compiler options
  • Get the latest Delphi version

I personally found one of such bugs to be resolved if I turned off Range Checking. Others are solved if you don't use generics from another unit. And one was solved if the unit name and class name was renamed to be smaller.

And of course you should report any problem you have on http://qc.codegear.com

Upvotes: 5

Related Questions