Rio 10.3.1 IDE Compiler Error

[chkaufmann 17]

Hi,

 

we already missed 10.3, now 10.3.1 is available but we can still not move to the new version because IDE compiler errors are still not fixed. Our major project is quite large but what we found is, that this issue is probably the problem we have:

https://quality.embarcadero.com/browse/RSP-22307

 

What is the best way to get this fixed now? It's unresolved since 4 months now and having such a "show stopper" all the new fancy features in the IDE are just useless when such basics like the compiler don't work.

 

Christian

[Uwe Raabe 2057]

Are you sure that the bug report actually describes your problem and it really is a show stopper? According to the bug report it is something about the compiler not being able to infer the type, but explicitly mentioning the type works. How can that be a show stopper?

 

Nevertheless, as long as you are on an active subscription you have three support incidents per year included. You can burn one of them to ask for an individual fix for that issue, although there is no guarantee that this will succeed.

[Holger Flick 12]

5 hours ago, chkaufmann said:

What is the best way to get this fixed now? It's unresolved since 4 months now and having such a "show stopper" all the new fancy features in the IDE are just useless when such basics like the compiler don't work.

 

This does not qualify as a showstopper. You might feel like it, but it is not.

 

Especially as the error seems to be only appearing in certain situations, and it seems to be avoidable if you compile without the IDE.

 

In order to go ahead with your project, I would suggest to put the problematic class in a separate bpl and compile it using the command line. Then you can continue daily work inside of the IDE. 

[chkaufmann 17]

1 hour ago, Holger Flick said:

Especially as the error seems to be only appearing in certain situations, and it seems to be avoidable if you compile without the IDE.

Well, for me this kind of solutions are fine in the world of "Open Source Tools", but not when I'm forced to pay a subscription fee. 

 

In our case the compiler not even shows us the exact location. I just get the error "[dcc32 Fatal Error] F2084 Internal Error: DBG1226" during compilation, well in fact during linking. And the only QC report with this error I found is the one listed above.

 

So in the end I don't know where to search the error in a project with several hundred thousand lines of code. I use generic functions in different places, but having these removed is a "showstopper" for me.

 

Christian

[Holger Flick 12]

6 minutes ago, chkaufmann said:

So in the end I don't know where to search the error in a project with several hundred thousand lines of code. I use generic functions in different places, but having these removed is a "showstopper" for me.

Then, you should not have referred to that bug report if you are not certain what causes the error. Sadly, without producing a test-case, you will never get a resolution. This is sadly the case for commercial and open-source products.

 

It is painful, I agree, if a new version introduces unforeseen issues.

Again, there is a formal definition of a showstopper in QA. The term does not refer to your (or anybody's) ability to use the product or not.

[FredS 138]

1 hour ago, Holger Flick said:

if you compile without the IDE

 

Yeah, it most likely will go away if you compile with another language as well 🙂

[Sherlock 663]

Aw, come on guys...back to trying to solve the issue please.

[FredS 138]

14 minutes ago, chkaufmann said:

And the only QC report

Been running into:

F2084 Internal Error: AV0A33CEAC-R46DC0000-0

myself, so far 90% of the time it works when I recompile, occasionally I need to comment out a line then compile uncomment and compile.
 

Not very helpful but worth trying Resolving Internal Errors.

[Rudy Velthuis 91]

On 3/26/2019 at 4:41 PM, FredS said:

Been running into:

F2084 Internal Error: AV0A33CEAC-R46DC0000-0

myself, so far 90% of the time it works when I recompile, occasionally I need to comment out a line then compile uncomment and compile.
 

Not very helpful but worth trying Resolving Internal Errors.

In my experience, most internal errors I have seen occur when mixing generics with anonymous methods, or when relying on the new type inference. Look for code that does this. Often, declaring types beforehand instead of on the spot clears them.

[FredS 138]

1 hour ago, Rudy Velthuis said:

Look for code that does this

 

Right, its 163k lines of code that compile fine unless I switch to the DUnitX Build Configuration which is full of generics and anonymous methods and my implementation uses a ton of directives..

 

There is no logic, you can't comment out some fixtures and get it to work consistently but you can simply comment out any random line and compile twice to bypass it. Compiling in Rio seems to work, of course that has other issues..

 

Edited March 29, 2019 by FredS

[Stefan Glienke 2002]

Look for code that uses type inference - if that only happens with DUnitX config, then look for Assert.something calls

[FredS 138]

1 hour ago, Stefan Glienke said:

then look for Assert.something calls

Good idea but here is what happened:

1. Was unable to generate the Internal Error this morning
2. The Project Group also contains some components so I right clicked and ran 'Install'
3. After that a 'Build' generated the Error
4. Commented out all 'Assert.'
5. After a bit of tweaking all compiled
6. Was not able to reproduce the Error by running 'Install' again
7. Uncommented chunks of 'Assert.' until I could generate the Error
8. But commenting those back in still generated the Error after running 'Install'

As I have postulated for years, the compiler appears to get confused about which directory its in or something else internally goes haywire.
The degree of which appears to get better or worse with each release..

 

Just to be clear; 'Install' is executed via the context menu so the active project does NOT change in the Project Group. Certainly rhymes with the 'I did a few things and it broke' we see a lot..

 

[Rudy Velthuis 91]

On 3/31/2019 at 7:16 PM, FredS said:

Good idea but here is what happened:

1. Was unable to generate the Internal Error this morning
2. The Project Group also contains some components so I right clicked and ran 'Install'
3. After that a 'Build' generated the Error
4. Commented out all 'Assert.'
5. After a bit of tweaking all compiled
6. Was not able to reproduce the Error by running 'Install' again
7. Uncommented chunks of 'Assert.' until I could generate the Error
8. But commenting those back in still generated the Error after running 'Install'

As I have postulated for years, the compiler appears to get confused about which directory its in or something else internally goes haywire.
The degree of which appears to get better or worse with each release..

 

Just to be clear; 'Install' is executed via the context menu so the active project does NOT change in the Project Group. Certainly rhymes with the 'I did a few things and it broke' we see a lot..

 

Once you get an internal error, you should perhaps restart the IDE, because sometimes it seems to destabilize the compiler.

Edited May 6, 2019 by Rudy Velthuis

[FredS 138]

1 hour ago, Rudy Velthuis said:

should perhaps restart the IDE

Yeah, except yesterday I tried to compile that project via msbuild and it still generated the same error:

[Rudy Velthuis 91]

7 hours ago, FredS said:

Yeah, except yesterday I tried to compile that project via msbuild and it still generated the same error:

Can you compile with the command line compiler?

 

Problem is that an internal error is a bug in the compiler or linker, so it is extremely hard to work around. One can give some general advice, but it is not sure that that always works. AVxxx seems to hint at an AV somewhere.

[FredS 138]

6 hours ago, Rudy Velthuis said:

extremely hard to work around

Not an issue, as I said before 99.9% of the time recompiling fixes it. For the remainder, commenting out a line , any line, do a build all then uncommenting the same line will fix it..

 

[Rudy Velthuis 91]

4 minutes ago, FredS said:

99.9% of the time recompiling fixes it. For the remainder, commenting out a line , any line, do a build all then uncommenting the same line will fix it..

Weird, very weird...

[AlekXL 8]

actually, the only way to fix it is to have  compiler opensourced and local skilled software engineer hired --   to investigate such issue. He could resolve issue, and then report it!

So vote the issue

 

Edited May 8, 2019 by AlekXL

[Rudy Velthuis 91]

9 hours ago, AlekXL said:

actually, the only way to fix it is to have  compiler opensourced and local skilled software engineer hired --   to investigate such issue. He could resolve issue, and then report it!

So vote the issue

 

That is off-topic.

[AlekXL 8]

23 hours ago, Rudy Velthuis said:

That is off-topic. 

I would politely disagree.

[David Heffernan 2345]

Public service announcement:

 

If you don't reply to a comment that is leading nowhere, the thread just ends. 

Edited May 9, 2019 by David Heffernan

[Rudy Velthuis 91]

16 minutes ago, David Heffernan said:

Public service announcemen:

 

If you don't reply to a comment that is leading nowhere, the thread just ends. 

If so, then you replied to a comment that doesn't lead anywhere. I was going to stop after the comment.

But we all know that threads do not just end like that.

 

But telling something is off-topic and then stopping the discussion does make sense, IMO.

So if you don't prolong it, it works.

Edited May 9, 2019 by Rudy Velthuis