Delphi 11.3 unusable due to full-build-requiring onslaught of F2084 "Internal Compiler Errors" from minor source modifications

[PaulM117 2]

The alleged "quality focused update" of Delphi 11.3 Professional, which Embarcadero wants to charge me $850 for despite the fact that I already own Delphi 11.1, has represented an utter disaster of usability and product quality to me further indicative of the decline of Delphi IDE's competency and stability in the past years rather than improvement.

 

I am afflicted by a perpetual state in which even the most minor one-line source edits (even changing a constant number like "2" to "1" in an arithmetic statement) forcibly requires me to do a time-consuming full "Build All" or else I will get repeatable, infinite "dcc32 Fatal Errors" and "F2084 Internal Errors" which are 100% the fault of Delphi.

 

At least in 11.1 I could usually do an annoying "Clean" + "Compile" workaround; this is even worse in 11.3. This seems to affect my newer source code units (where I am working) but happens less frequently in older source units.

 

Quote

[dcc32 Fatal Error] probe.pas(750): F2084 Internal Error: AV6B69A1EA(6B620000)-R0000030F-0
[dcc32 Fatal Error] map_labeling.pas(355): F2084 Internal Error: AV6B64A1EA(6B5D0000)-R1274003C-0
[dcc32 Fatal Error] map_labeling.pas(371): F2084 Internal Error: AV6B64A1EA(6B5D0000)-R8B00256C-0
[dcc32 Fatal Error] sprite_engine.pas(513): F2084 Internal Error: AV6B6F584D(6B670000)-RF4000209-0
[dcc32 Fatal Error] text_rendering.pas(576): F2084 Internal Error: AV6B6F584D(6B670000)-R00000209-0
[dcc32 Fatal Error] map_labeling.pas(462): F2084 Internal Error: AV6B6FA1EA(6B680000)-R77F29F42-0
[dcc32 Fatal Error] text_rendering.pas(590): F2084 Internal Error: AV6CFA584D(6CF20000)-R00040209-0
[dcc32 Fatal Error] render.pas(2259): F2084 Internal Error: U12366
[dcc32 Fatal Error] probe.pas(753): F2084 Internal Error: SY7449

I have tried, to no avail:

1. Changing encoding from ASCII to UTF-8

2.  -cleanregistryide directive

3. Uninstalling GExperts

4. Messing with the "use MSBuild external compile" option (which was already on)

5. Ensuring that IDE memory consumption is minimal (it's WAY under the threshold where it changes cache behavior)

6. Ensuring "Enable unit directory cache"  is enabled

 

This insane problem has cratered my productivity and utterly annihilated the one major benefit Delphi has over C++ which is fast compile times, because I have to do a full build every time.

 

Yet Embarcadero has the audacity to want to charge me $850 for a minor subversion upgrade where I could have started clean and fresh with MS Visual Studio / C++ for absolutely free even for commercial use.

 

The remaining and degraded issues in 11.3 are not only the broken compiler. Does anyone else experience the following:
1. The Win64 debugger totally stopped working for me months ago even on 11.1. No breakpoints work; they appear Xd-out as if compiled in release mode or as if placed in an inline function. Win32 debugger breakpoints work fine.

2. The inline constants/vars display in the debugger is totally broken showing false values that are not identical to the actual values of inline vars actually running in code (still not fixed in 11.3)

3. Uniquely to the difference of 11.1, I have witnessed in 11.3 multiple examples of minor code changes in saved Pascal unit files not correctly updating/generating new code upon a rare successful "Compile" (I can rarely use quick "Compile" and not a full build in old source units, like I mentioned above), and rather I have to force a full rebuild to effectuate these changes. This never happened in 11.1. I.e., it's possible to make code edits in 11.3, and get a successful compile, that never actually changed the binary compiled code in those areas.

4. Frequently the entire IDE will freeze on a competent $2k 2021 Asus Expertbook laptop during compilation and I must terminate in task manager and restart the whole IDE. This rarely happened on older versions. The way the Delphi IDE freezes is unique; it does not trigger the Windows "this program is not responding" dialog. It's almost as if it's using the Win32 API window disable flag to simulate a complete freeze while giving the user false hope the compiler is just doing a hard part and will return temporarily.

5. Code generation and optimizations are still extremely lacking in dcc32/64 compared to industry standard C++ compilers. What an embarassment! Why do we have to live with such Stockholm Syndrome here to the point that Embarcadero brags about how optimized their Move routine is in 11.3 (when it was actually just completely horrible before, and still is apparently not as good as C++ implementations). Very frustrating that my reversion to 11.1 makes it apparently impossible to use the new faster Move routine in built-in RTL operations, since I was totally unable to recompile System.pas when I altered it with the new Move.

 

Any experience, information, help, or fellow developer commiseration on the current state of Delphi 11.3 is welcomed and solicited.

[Brian Evans 105]

Get another developer to clone/copy one of your projects and try working on it. Have them copy / duplicate NOTHING of your system/network/software/development configuration. Something sounds off with your system/configuration/network/etc. 

 

Long IDE freezes can be as simple as dead paths being searched - Windows can take a long time to timeout checking a network drive where the other side doesn't respond at all for example and Delphi tends to re-search the same paths often making it take even longer. The worst would be an intermittently accessible path / storage location which would cause all sorts of hard to discern problems. Even bad sleep/resume of a storage device can cause problems or delays. 

 

For all the internal errors - if they happen reliably you might be able to narrow it down to small test case(s) - they usually do get fixed if there is a reliable way to reproduce both so they can see the error and test a fix. 

[programmerdelphi2k 237]

as we can see here, the said member is in an advanced stage of discounting and returning to the said programming language, one of the most effective solutions being, in this case, changing to another . (since nothing satisfies him for a long time).

 

On the other hand, I believe that the real problem is your own inability from the beginning of your project, perhaps mistakes after mistakes that were circumvented at a high price at every moment. I think the most sensible thing would be to review all the code (something that may take a lot of time and resources, but necessary at this stage).

 

As it may not be something very viable at this point in the championship, so it's more comfortable to blame the programming language... (of course, Embarcadero is very much to blame, no doubt.... but that's the life of a programmer)

[tinyBigGAMES 53]

1. If you have not done so, make sure you have excluded all Delphi related folders + your project folders from real-time virus scanning

2. ASLR is enabled by default so there may be places in your code that are now suddenly invalid whereas it worked perfectly before. There may be places where you must use NativeInt/NativeUInt instead for example. So, check for ASLR related issues that may exist in your code base.

 

After doing the above, the constant AVs and crashes diminished for me. 

[Mark NZ 0]

I also get a large number of AV's when compiling via the IDE, started prior to Delphi 11.1, still a problem in D11.3, just got into the habit of always building.  We do use MSBuild (think this was due to build errors if we didn't).  I encounter a number of other errors with the IDE and it's not feasible to spend time attempting to chase them down 😞,  I have at times attempted to reproduce some of bugs with simple reproductions steps and have raised Jira issues for these and VCL bugs.  Embarcadero have even fixed some of those, the others are waiting for them to look at. 

I suspect a number of issues are related to project size - and for the person who said to review every line of your code, if we allowed 2 seconds per line that'd be half a year of full time work, for just one of our projects. Yeah, nah.

 

With regards to AV checking I'm going to look at that, we're already be excluding our own source code as have run into a handful of problems with Sophos if we don't.

[KenR 29]

With very large projects I find that compiling it in 32 bit mode then compiling it in 64 bit mode crashes Delphi. This happens every time with multiple projects!

[Lars Fosdal 1792]

- check that you don't have stray .dcu files

- ensure that all projects build .dcus into different folders for 32-bit and 64-bit

- If you have circular unit use, see if you can refactor and apply dependency injection

 

[David Heffernan 2345]

18 hours ago, programmerdelphi2k said:

as we can see here, the said member is in an advanced stage of discounting and returning to the said programming language, one of the most effective solutions being, in this case, changing to another . (since nothing satisfies him for a long time).

 

On the other hand, I believe that the real problem is your own inability from the beginning of your project, perhaps mistakes after mistakes that were circumvented at a high price at every moment. I think the most sensible thing would be to review all the code (something that may take a lot of time and resources, but necessary at this stage).

 

As it may not be something very viable at this point in the championship, so it's more comfortable to blame the programming language... (of course, Embarcadero is very much to blame, no doubt.... but that's the life of a programmer)

 stockholm syndrome 

[Lars Fosdal 1792]

Another Q:

Do you have third party components/libs without sources and with .dcus compiled with a previous 11.x version?

[Clément 148]

It doesn't seem to be a dproj or dpr related, but how old is your .dproj ? Have you create a new one for 11.x?
Are all your .pas files in you dproj? if not, make sure your are deleting all dcus files manually prior to rebuild. For example, if you select "CLEAN" the IDE will delete only the files present in your dproj, you might get some old dcus in your built!
If this is the case, third party dcus are the first you need to check.

 

 

[KenR 29]

8 hours ago, Lars Fosdal said:

- check that you don't have stray .dcu files

- ensure that all projects build .dcus into different folders for 32-bit and 64-bit

- If you have circular unit use, see if you can refactor and apply dependency injection 

  

Projects were recreated, and have different folders for DCU's. If I re-open Delphi the project compiles fine. The problem only exists when switching between 32 and 64 bit.

[programmerdelphi2k 237]

I think that this is old-problem in IDE (to +/- big project)... anything, a re-RUN-IDE should ok, not?

Edited March 20, 2023 by programmerdelphi2k

[Pat Foley 51]

When I switch from 64 to 32 I use the syntax check to (alt-p-s) Before the compile. 

The issue in a package. 

 

Pat

[Lars Fosdal 1792]

15 hours ago, KenR said:

The problem only exists when switching between 32 and 64 bit.

That is a significant detail that should have been in your original post, which gives the impression that 64-bit is completely borked as a whole.

 

There are some reports on similar issues when switching platforms in the QP - so it seems that it is not uncommon, but some of the reported issues have been closed with "unable to reproduce".
My suggestion would be to try to narrow down the behaviour to a minimal example and submit it to QualityPortal.

It can only be fixed if the problem can be reproduced. 

[Dalija Prasnikar 1396]

14 hours ago, Pat Foley said:

When I switch from 64 to 32 I use the syntax check to (alt-p-s) Before the compile. 

I have noticed that switching between platforms often chokes if you just compile or do syntax check. Full build works. It seems like some internal compiler status or cache is not properly cleaned during platform switching. 

 

However, I haven't been able to create small reproducible test project to report the issue and I don't switch platforms that often so I never tried to investigate deeper. 

On 3/19/2023 at 3:12 PM, PaulM117 said:

6. Ensuring "Enable unit directory cache"  is enabled

The issue sounds like it is cache related, so I would say that enabling cache option might be counter productive. Try disabling the cache and see how it goes.

[Dalija Prasnikar 1396]

18 minutes ago, Lars Fosdal said:

My suggestion would be to try to narrow down the behaviour to a minimal example and submit it to QualityPortal.

@PaulM117 like Lars suggested, if you can create test case, please submit a bug to Quality Portal. However, even if you cannot create reproducible test case, submitting a bug report (with as much information as you can provide) might still be a good choice as at least it gives some feedback to Embarcadero that there is something seriously broken in the area.

[Sherlock 663]

Well, a platform change comes with a bunch of changes to compiler directives. And it has been my knowledge, that those only really take after a full build because some of the DCUs may be considered clean even though they have been compiled with a different set of directives. So of course you need to fully build after switching the platform.

[Uwe Raabe 2057]

That is not needed when the dcu folder is configuration and platform specific using something like $(Platform)\$(Config). That way the existing dcu files in that folder are compiled with the last settings for that platform and configuration.

If working with several projects it also helps to have separate dcu folders for each. Some use $(SanitizedProjectName) for that.

With this approach I have no problems switching platforms, configurations or projects. I very rarely make changes to the directives in a project configuration. If that turns out to be necessary I'd rather add another (child-)configuration with separate dcu folders.

 

BTW, avoiding circular unit dependencies gives a significant performance boost for Code Insight.

[Pat Foley 51]

1 hour ago, Dalija Prasnikar said:

have noticed that switching between platforms often chokes if you just compile or do syntax check. Full build works. It seems like some internal compiler status or cache is not properly cleaned during platform switching. 

So, when error 2048 shows after switching platforms; Just switching back clears it. Which is pretty cool that 11.3 can recover.   

 

The Syntax check magic does not work as well when installing a package.  That needs to be compiled to lose the vintage dcus/BPL.  In my case ignoring compiler warning about implicit files in a package build results in error 2048.  I just don't know how make separate include files for the different platforms and perhaps csDesigning mode bypass  so procedure not used in design mode is needed.       

[PaulM117 2]

Thanks for the responses, particularly to David and Dalija, whose printed and internet-published educational works have greatly aided my Delphi expertise throughout the years.

 

I have data suggesting 80% of the theories and recommendations in this thread are certainly non-responsive and that what I am experiencing is indeed a unique compiler issue limited to certain "cursed" newer source files which do not differ in language feature usage from other older source files which do not exhibit this problem (I had thought perhaps using things like generics, inline vars, or inline function directives, or something like that, could trigger this, but this is not identifiable in my codebase between smaller, new units repeatably triggering this issue and larger, older source units which do not).

 

The other 20% of feedback in this thread (particularly, some of Lars's points) gives me some homework to do before I post a more rigorous reply here trying and discounting theories.

 

Of note, I reverted to 11.1 and the same issue does exist. However, the full build seems much faster in 11.1 than in 11.3 and the repeat freezing/crashing-mid-full-build issue seems much worse/more common in 11.3, so 11.3 is still a downgrade for me even while admitting that the gravamen of my thread (the full-build-requiring condition on some magical "cursed" source units from de minimis source changes thereto but not on others) is an issue that precedes 11.3.

 

 

Edited March 21, 2023 by PaulM117

[Mark NZ 0]

I can confirm that in my case the compiler compile AV's happen without switching between project/build configurations (and over multiple Delphi versions), hopefully the 32/64bit is a more reliable trigger though for the same issue (might make it easier to find).