Internal Error 200611031

[fjabouley]

Hello all !
I'm facing an annoying issue since very long time in a project.
Randomly, I got this error that happens when I compile the code (Internal Error 200611031) I have to remove a line before the one that leads to the error and insert it back to make it go on.
When the error happens, I have to do the same process for 4 lines (remove/insert, then press F9, then it shows the error on another line, then I remove the n-1 line, and insert a blank one, etc....) to make the project compile and run...
Is there a mean to correct that, what could I do ?
Thanks for your answers! 
Regards

[Warfley]

Have you tried a cleanbuild when this occured?

I had a similar internal error (not exactly that one) which only occured in projects if the size was so big I couldn't reduce it to a meaningfull bug report, but cleanbuilding always works

[Thaddy]

I had a similar internal error

That is highly unlikely to mean the same. Internal errors are just a date stamp and a ordinal and not related to content.
Just grep the sources..... then you know where it is.
And subsequently have a broad idea what it means.
It is on line 1012 of symsym.pas or there about :

Code: Pascal  [Select][+][-]

1.        { Clear all procdefs }
2.         ProcdefList.Clear;
3.         if not assigned(FProcdefDerefList) then
4.           internalerror(200611031);

People who do not have a license should not drive.... 

(maybe there should be a wiki entry on how to trace internal errors: grep on the compiler directory first)

[howardpc]

I suggest you remove all the unused private fields, unused local variables and unused units the compiler tells you about.
This won't cure the problem, but it will reduce clutter and enable you to pay attention to compiler output that really matters (as well as reducing your code size and very slightly speeding up compilation).
Since the internal error is probably to do with a procedure symbol, I suggest you then rename List_Calls_HTML to some other unique name, do a clean rebuild and see what the compiler tells you next.

[Warfley]

That is highly unlikely to mean the same. Internal errors are just a date stamp and a ordinal and not related to content.
Just grep the sources..... then you know where it is.

I meant with this an error that only occured sometimes and after editing these lines (or after a cleanbuild) the error didn't occur. Of course the error wasn't the same, but it's occurance and lack there of behaved similar. Or are you saying that two different errors can't have the same occurance behaviour? In that case feel free to elaborate why

[Thaddy]

Or are you saying that two different errors can't have the same occurance behaviour?

It is unlikely based on internal errors, but it is possible that some internal errors are caused and show close to the same behavior, although that is statistically highly unlikely.
Internal errors are written into the code to specify unwanted behavior regarding a specific piece of code and go waaayyyyy beyond exceptions.

In this case it looks like a use after free.
Any internal error you encounter should always be reported on the bug tracker..

[Warfley]

Any internal error you encounter should always be reported on the bug tracker..

I know, but I can't report a 10kloc project of code that not 100% belongs to me to the bugtracker. And the funny thing about this is, that as soon as I remove substantial amounts of code this error disappears. It doesn't even matter what parts of the code I remove, to me it seems like it's a problem as soon as the project gets to big

although that is statistically highly unlikely.
Internal errors are written into the code to specify unwanted behavior regarding a specific piece of code and go waaayyyyy beyond exceptions.

You are assuming independence here. Two pieces of unwanted behaviour can still have the same root cause, that just manifested differently. For example if you work on faulty data, a meriad of different errors can occur, even though the cause of the faulty data could always be the same.

Or a concrete example, use after free. This can result in accessing another object of the same kind so you have kindof coherent data with what is expected, it can access a new object at that location, resulting in completely gibberish, it could access the old object which wasn't overridden yet, or it could result in a segfault. These are a bunch of different errors, all stemming from the same root.
An assertion testing for coherent data might not fail in the case of a new object of the same type and accessing the old object, but on a different object it might fail. While a reference check (like checking the name) might fail even on a new object of the same type, but not on accessing the old object.
I would even go so far to say, if you access unknown, random heap objects (which use after free is) pretty much anything can happen. Maybe you override a switch which causes the program to draws a bunch of unicorns all over the screen, who knows, everthing is possible when accessing memory that doesn't belong to you

[Thaddy]

With the risk of repeating myself:Any internal error you encounter should always be reported on the bug tracker..
Bar none.

This is not about possibly bad programming on the user side. It should not happen.
You will be much obliged if you can provide a simple example, though.

[fjabouley]

Have you tried a cleanbuild when this occured?

I had a similar internal error (not exactly that one) which only occured in projects if the size was so big I couldn't reduce it to a meaningfull bug report, but cleanbuilding always works

Thank you all for your answers !
When I clean and build, it then compiles well.
The issue is happening on my main unit, which has about 25k lines of code. The other units are smaller and don't face that problem. May Splitting the main unit into smaller ones solve this ?
Best regards !

[PascalDragon]

Or are you saying that two different errors can't have the same occurance behaviour?

It is unlikely based on internal errors, but it is possible that some internal errors are caused and show close to the same behavior, although that is statistically highly unlikely.
Internal errors are written into the code to specify unwanted behavior regarding a specific piece of code and go waaayyyyy beyond exceptions.

Considering that the internal error is in the sym's deref method it's in fact very likely to be related to the loading of compiled units and thus doing a clean build where all units are recompiled will indeed solve this as that method won't be used then.

In this case it looks like a use after free.

Nope. More likely some code f***ed up when loading the unit or even when writing it during the previous compilation.

Any internal error you encounter should always be reported on the bug tracker..

It would definitely be nice to be able to reproduce it with a smaller sample, though these kind of bugs more often than not only creep up with bigger projects...

[fjabouley]

Hmm, I did compile a few times since I cleaned and built, and then the error came back.
I got huge amount of visual components in the main unit, could it be related ?

How could I debug that ? Is there any way ? Is there a way to deep clean the code ? Or Have I to rewrite everything or split the main unit into small parts ?
Best regards !

[simone]

I have a similar problem in a not small project (about 30KLoc) that I have been carrying out for years. The error occurs randomly but very often. The size of the project does not allow me to easily generate a piece of code that reproduces the error in a deterministic way. To make matters worse, starting with version 3.2.0 I also often (but less frequently) see the following terse message: "Compilation raised exception internally" . Never seen this message in so many years. This phenomenon is creating a bit of a nuisance in my development activity. To mitigate this, I added an instruction at startup of my program that deletes the 'lib' directory containing the .ppu and .o files.

[fjabouley]

I have a similar problem in a not small project (about 30KLoc) that I have been carrying out for years. The error occurs randomly but very often. The size of the project does not allow me to easily generate a piece of code that reproduces the error in a deterministic way. To make matters worse, starting with version 3.2.0 I also often (but less frequently) see the following terse message: "Compilation raised exception internally" . Never seen this message in so many years. This phenomenon is creating a bit of a nuisance in my development activity. To mitigate this, I added an instruction at startup of my program that deletes the 'lib' directory containing the .ppu and .o files.

Same here, don't know if posting the whole code would be useful ?
Isn't there another method to know what's happening ?
Thanks everybody for your answers !

[jamie]

way back when I decided to try Lazarus, I think that time it was using 2.7.x compiler.. I found it could not handle complex IF statements with deep operations and thus generate these sorts of errors and it seem like it had a lot to do with code prior to it. Because if i took that complete IF statement to make a test app to demo the problem it would always work.  It was related to the compiler already working on a lot of code in the same block when it encountered this complex deep code set that involved casting over arrays in multiple AND, OR etc

 So these types of errors are hard to reproduce due to the nature of how they get that way..

 could be local resources running dry on complex code.

[fjabouley]

way back when I decided to try Lazarus, I think that time it was using 2.7.x compiler.. I found it could not handle complex IF statements with deep operations and thus generate these sorts of errors and it seem like it had a lot to do with code prior to it. Because if i took that complete IF statement to make a test app to demo the problem it would always work.  It was related to the compiler already working on a lot of code in the same block when it encountered this complex deep code set that involved casting over arrays in multiple AND, OR etc

 So these types of errors are hard to reproduce due to the nature of how they get that way..

 could be local resources running dry on complex code.

So do you think it is some kind of fate ? Is there anything to do to deal with it ? I'll try splitting the main unit moving most of the functions/procedures in a new one and see if this is happening again.
Many thanks for all your answers !