Reputation: 5050
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
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
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
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
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
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
Reputation: 11
Disabling "Include remote debug symbols" from the Linker Options fixed the issue for me Delphi 2007, dll project
Upvotes: 1
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
Reputation: 5615
For me, in D2010 disabling the compiler option "Emit runtime type information" did the trick.
Upvotes: 0
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
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
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
Reputation: 5050
I managed to solve this, following the below procedure
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
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:
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