Forum > General

"Compilation raised exception internally" on recent 3.3.1 compiler builds

(1/4) > >>

Paradice:
All of the recent development builds of fpc 3.3.1 (up to and including the current build from May 20th 2024) have started throwing an unhandled exception error when compiling my largest project. Target and platform are both Win32/i386. Compiler builds compiled with FpcUpDeluxe. Not using Lazarus at all.

I have a compiler from 3.3.1 dev branch version from Feb 27th 2024 which compiles everything successfully, but newer versions bug out. (not sure exactly what date it failed, I only rebuild FPC every month or so - it's been failing for the past ~3 months).

With recent versions, using -B to build all sources will work as expected, but even immediately after that, attempting a simple recompile of any source file within the project without -B will trigger this error. Unfortunately, reducing it down to a "minimum source to reproduce the error" is tricky, I'm only experiencing this on my main project which is probably ~150 units of various interconnections. Which unit is the last unit "Compiling" before the exception varies, but it seems to always be 3 or 4 units after whatever I first attempt to compile.

Any advice on what to look into? I'm not very experienced with git, hence using FPCUpDeluxe to compile FPC for me.

---
Command line:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---E:\FPC\3.3.1\bin\i386-win32\fpc.exe @E:\Projects\.Meta\FPCsettings331.cfg -dDEBUG E:\Projects\Paradice500\Paradice500.pp----
Output:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---Free Pascal Compiler version 3.3.1-15711-geff10ee9b7 [2024/05/20] for i386Copyright (c) 1993-2024 by Florian Klaempfl and othersTarget OS: Win32 for i386Compiling E:\Projects\Paradice500\Paradice500.ppCompiling E:\projects\lx7\lx7core.ppCompiling E:\projects\lx7\lx7debug.ppCompiling coreStrings.ppError: Compilation raised exception internallyFatal: Compilation abortedAn unhandled exception occurred at $00437B8A:EAccessViolation: Access violation  $00437B8A  $0056A0FD  $0056A74D  $0056AA9C  $0056A284  $0056A74D  $0056AA9C  $0056A0E4  $0056A74D  $0056AA9C  $0056A0E4  $0056A74D  $0056AA9C  $0056A0E4  $0056A74D  $0056AA9C  $005B4C37

jamie:
I don't fully know the switches of the compiler, nor should there be an error like that, which of course is a reportable error.

But, with Laz, I elect to use an external debug file so that it does not attach itself to the EXE., makes it much smaller.

Maybe you are running out of space and the compiler is not catching it at the correct moment?

Eugene Loza:
Unfortunately things like that happen, and there isn't much you can do about that. If clean-up and build fixes the issue, then you might as well just create a script to delete all o and ppu files in the temporary output folder - this is slightly faster than recompiling the project and all dependencies.

Cutting your project down to minimal reproducible example for a bugreport is almost the only way you can try dealing with the issue. Yes, it takes time (last bugreport took me >3 hours to cut from 40k lines down to 70). Making a bisection of FPC history to find a specific commit that started the bug also may help. Yes, eventually the result may be very delayed - as someone smart enough will need to investigate your bugreport and spend a ton of time understanding what is going wrong and how to fix it.

There is also an option to rewrite/simplify the code, it seems like convoluted generic operations are very prone to confuse FPC. But for that you need to try to figure out what exactly goes wrong. It may help if you get a debug build of FPC, see attached image on how to do that in FPCUpDeluxe.

Paradice:
Thanks for your help, Eugene! - I've recompiled the compiler in debug mode to see if it gave me any clues... now I'm getting this output:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---E:\FPC\3.3.1\bin\i386-win32\fpc.exe @E:\Projects\.Meta\FPCsettings331.cfg -dRELEASE E:\Projects\Paradice500\Paradice500.ppCompiling Release VersionCompiling Release VersionHint: End of reading config file E:\Projects\.Meta\FPCsettings331.cfgFree Pascal Compiler version 3.3.1-15713-gcab3b8c06f [2024/05/20] for i386Copyright (c) 1993-2024 by Florian Klaempfl and othersTarget OS: Win32 for i386Compiling E:\Projects\Paradice500\Paradice500.ppCompiling E:\projects\lx7\lx7core.ppCompiling E:\projects\lx7\lx7events.ppCompiling coreStrings.ppError: Compilation raised exception internallyFatal: Compilation abortedAn unhandled exception occurred at $00438D2A:EAccessViolation: Access violation  $00438D2A  TMODULE__ADDDEPENDENCY,  line 1005 of fmodule.pas  $0056B2CD  TPPUMODULE__LOAD_USEDUNITS,  line 1958 of fppu.pas  $0056B91D  TPPUMODULE__TRY_LOAD_PPUFILE,  line 2221 of fppu.pas  $0056BC6C  TPPUMODULE__LOADPPU,  line 2362 of fppu.pas  $0056B454  TPPUMODULE__LOAD_USEDUNITS,  line 2014 of fppu.pas  $0056B91D  TPPUMODULE__TRY_LOAD_PPUFILE,  line 2221 of fppu.pas  $0056BC6C  TPPUMODULE__LOADPPU,  line 2362 of fppu.pas  $0056B2B4  TPPUMODULE__LOAD_USEDUNITS,  line 1953 of fppu.pas  $0056B91D  TPPUMODULE__TRY_LOAD_PPUFILE,  line 2221 of fppu.pas  $0056BC6C  TPPUMODULE__LOADPPU,  line 2362 of fppu.pas  $0056B2B4  TPPUMODULE__LOAD_USEDUNITS,  line 1953 of fppu.pas  $0056B91D  TPPUMODULE__TRY_LOAD_PPUFILE,  line 2221 of fppu.pas  $0056BC6C  TPPUMODULE__LOADPPU,  line 2362 of fppu.pas  $0056B2B4  TPPUMODULE__LOAD_USEDUNITS,  line 1953 of fppu.pas  $0056B91D  TPPUMODULE__TRY_LOAD_PPUFILE,  line 2221 of fppu.pas  $0056BC6C  TPPUMODULE__LOADPPU,  line 2362 of fppu.pas  $005B5E07  LOADUNITS,  line 681 of pmodules.pas
So, progress.. it's definitely something to do with units I'm including, somehow (maybe order?). I am guilty of several cases of a unit using another unit in it's interface, and the secondary unit uses the original one in it's implementation. It never feels great doing this but it hasn't caused any issues up until now.

This weekend I will try patiently carving chunks of units & functionality out of my project and see if I can narrow down what's causing the error. I suspect that all of the complexity is what's actually causing the error though so making it easily reproducible is not going to be easy at all.


@Jamie - pretty sure it's not related to my system at all. No problems with space, and have tried the same source files on a couple of different systems (one Intel, one AMD) and different directory structures - same issue on both.

Eugene Loza:
Hmmm... it doesn't look any more helpful to me other than what you've already seen without debug build, that it fails somewhere around coreStrings.pp (hopefully inside of it) as it tries to LOADPPU (i.e. reuse a prebuilt unit, seems like of one of the dependencies of coreStrings.pp).

I wonder if Lazarus can give you a more verbose error stack trace? I see you are using complicated compilation configuration, I wonder if you can try setting it up through Lazarus or making a "less configured" build? Because in my cases it usually points to some line of code inside of my code which may be directly or indirectly related to the error you experience.

Navigation

[0] Message Index

[#] Next page

Go to full version