Internal Compiler Error (063522DEH : 063449A8H)..?

1

Hi guys, I need help, sometimes after I compile an error appears in the compilation list… if I try to open the error embed it displays a message window, and the embed no longer opens.
And sometimes the Clarion crashes.
Today this happened and now it’s giving a compilation error on the first line
Internal Compiler Error (063522DEH : 063449A8H) - C:\CodFonte_ Cw111-Cod_multvet\Abertura.clw:1

In cw, a ~ appears on top of the member, I don’t know what it is…

image
image657×619 33.3 KB

2

Sometimes weird stuff at the top could be that there’s a unicode BOM, which can happen when you paste code from a web browser or something.

3

Internal Compiler Error means that the exception occurred while the compiler tried to compile displayed source file. The first number is an exception address, second one after colon is the address of the COMPILE function exported from the compiler DLL. This second address allows to calculate the address exception point in the compiler file. Usually this is enough to locate the problem. I have no the CLW compiler from the rel.13815. The code on relative position calculated for the last compiler I have access to has couldn’t cause the exception.

If you can send me the CLACLW.DLL you’re using and the first line “as is” of the source file the exception occurred on, it would be possible to determine actual roots of the problem.

2 Likes
4

Hi

Was there a clear solution to above problem?
Have just encountered a similar problem
Only when compiling a specific app, other apps compiling fine.
Internal Compiler Error (06CE2632H : 06CD4930H) - C:\dev\C10\tvc\tvcda_SF.CLW:1

Have tried several things I thought could help,
like
clearing out the OBJ files,
re-generating source cleanly,
restoring backup .app file
no luck

Any ideas or pointers greatly appreciated
thanks
Johan

5

Hi,

I did some DCT changes and after that I had the error.
I went back and did a few more changes to the 3 data files that I changed, added some dummy fields.
Complies fine now.

Something seems to have gone out of it’s orbit, all back in line again.

Johan

6

If you have sources the exception occurs on or if you can roll your last changes back temporarily, please send me files required to reproduce the compiler’s fault. Of course, if there is a willing to have this problem fixed in future versions of the CLW compiler.

7

Hi,

Compiling with the old DCT causes the compile error again.
What files do you need to check?

Johan

8

Hi,

Created a sub folder with APP and DCT that creates the error on compile
If you let me know where to send, I can do so

regards

Johan

9

Thanks to Johan roots of the exception in the compiler were found:

  1. The compiler manages dynamically allocating memory using pools rather than heap. This is logical because allocated objects are freeing at the same time. Particularly, separate pools are using to keep information about identifiers and their names/labels. The compiler reserves quite large blocks for every pool but not all the reserved memory is committing at once. Instead that, the new region is committing if remaining size of already committed memory is less than the requested size for an object to be allocated.
  2. 3rd party stuff usually place INCLUDEs in the main program module. As result, these includes are involving into compilation of every not-generic MEMBER module. If the program uses numerous 3rd party products, large number of include files are involving into compilation and thus the compiler has to handle huge number of identifiers. Consecutively, new regions of identifier-related pools are committing multiple times.
  3. The colon character in Clarion is using not for separating identifiers themselves and their prefixes only but as normal characters in identifiers too. Thereby, the algorithm of finding the “main” part in the prefixed identifier is not simple. There was a bug in the function realizing such algorithm - under certain conditions it could increment the loop’s index variable twice => skip one character. If the identifier name was allocating exactly at the tail of last committed region, this bug could cause attempt to access the byte beyond the committed region.

Though the bug with processing identifiers appeared at least in CW 2.0, it was rare before last time, in my opinion, because of reasons described in (2). The the error in point (3) was found and fix for it was sent to RZ several months ago but it was not included to public releases yet. Thanks to Johan it was proved that this fix must cure the problem.

5 Likes
10

I also encountered a similar problem, internal error. I have an application where I added SQLite table, the problem occurs. out of the 29 APP’s only 1 APP encounters the problem. The APP are all source codes accessing SQL file (MariaDB). I added a window and defined some TPS and SQL tables. The APP compiled successfully. Weird but it worked.

11

Thanks, but the thanks goes to you and all your hard work behind the scenes.

It was just lucky that I managed to isolate the app and dct into a folder and was able to rollback and reproduce the error.
I created multiple copies of the folder as I was worried that the compiler error could go away with any change in the source files on the recovery process of the app file from the previous crash.

It gave me a tiny insight into the enormous complexity behind the lines on that output tab in the IDE, absolutely mind boggling.