Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2015-10

Exception problems in FPC 3.0.0

9 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sergio Flores

Hi guys, congrats for the 3.0 release!

However after upgrading FPC, my Android game now crashes with division by zero exceptions (it happens always in the same place).

I changed nothing in the code, only the compiler changed from a 2.7.x to 3.0.0 (cross compiler windows to Arm binary version obtained from the link that was distributed in the mailing list last week). If I revert to using the old compiler, no exceptions happen.

Note that I have this line in one of my units:

Initialization
SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow,
exUnderflow, exPrecision]);
End.

I masking all of those stuff because it is a requisite for OpenGL graphics.

Looking at the breaking changes section of the wiki, I dont see anything related. Anyone has an idea of what changed that could cause this or at least how I can debug it?

Reply by email

Yury Sidorov
to Sergio Flores
Sergio Flores wrote 22 lines
Hi guys, congrats for the 3.0 release! However after upgrading FPC, my Android game now crashes with division by zero exceptions (it happens always in the same place). I changed nothing in the code, only the compiler changed from a 2.7.x to 3.0.0 (cross compiler windows to Arm binary version obtained from the link that was distributed in the mailing list last week). If I revert to using the old compiler, no exceptions happen. Note that I have this line in one of my units: Initialization SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]); End. I masking all of those stuff because it is a requisite for OpenGL graphics. Looking at the breaking changes section of the wiki, I dont see anything related. Anyone has an idea of what changed that could cause this or at least how I can debug it?

I suppose your issue is caused by the following:
The 3.0 release arm-android cross compiler is bundled with units compiled with the soft float FPU emulation.
In such case SetExceptionMask() masks only softfloat exceptions. And if the OpenGL library uses true FPU code, its exceptions are not masked.

You can:
- build FPC units from sources with FPU support.

or

- use the following code to mask FPU exceptions:

procedure VFP_SetCW(cw : dword); nostackframe; assembler;
   asm
     fmxr fpscr,r0
   end;

...

VFP_SetCW($1F00);  // Mask all FPU exceptions

...

Yury Sidorov.

Reply by email

Joost van der Sluis

Did you compile fpc yourself, or used a binary release? If you did it yourself, please try 3.0.1. There was a last minute fix that did not make it into the source-archive.

Joost Op 26-10-15 20:39 schreef Sergio Flores:
Hi guys, congrats for the 3.0 release!

However after upgrading FPC, my Android game now crashes with division by zero exceptions (it happens always in the same place).

I changed nothing in the code, only the compiler changed from a 2.7.x to 3.0.0 (cross compiler windows to Arm binary version obtained from the link that was distributed in the mailing list last week).

If I revert to using the old compiler, no exceptions happen.

Note that I have this line in one of my units:

Initialization
SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]);
End.

I masking all of those stuff because it is a requisite for OpenGL graphics.

Looking at the breaking changes section of the wiki, I dont see anything related. Anyone has an idea of what changed that could cause this or at least how I can debug it?

Reply by email

Sergio Flores

Yury, I think you're right, I'm using the precompiled binary that indeed seems to been compiled in soft-fpu mode, so that would explain everything, as OpenGL is probably triggering hard fpu exceptions that are not being caught.

I tried your asm function, however adding it makes the app added it to initialization of my OpenGLES unit, Seems that just having the function laying around, even without calling it, causes the crash.

Checking the android log, it says the following:
E/AndroidRuntime(10684): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "TERRA_OPENGLES_$$_LOADOPENGL" referenced by "libterra.so"...

LoadOpenGL() is the only pascal function that is contained in this unit (it just loads the opengles library dynamically and assigns function pointers). For some reason, adding the assembler function to this unit makes this function disappear, what causes this very weird behaviour?

Full unit code here:
http://pastebin.com/h2gCcikd

Commenting both the function and the function call makes the game startup again without crashing (albeit still crashes whevener a float exception happens)

Probably recompiling FPC with hard float support would be the best solution, however compiling FPC in Windows is a frustrating game of trial and errors. I had written a .bat file that I used with 2.6.2, but it no longer works in 3.0.0. Once I have some free time I guess I will have to try discovering whats problem. Or if anyone has 3.0.1 compiled with hard-floats and can provide a download link, i would be thankful.

Reply by email

Yury Sidorov
to Sergio Flores
Sergio Flores wrote 27 lines
Yury, I think you're right, I'm using the precompiled binary that indeed seems to been compiled in soft-fpu mode, so that would explain everything, as OpenGL is probably triggering hard fpu exceptions that are not being caught. I tried your asm function, however adding it makes the app crash at startup. I added it to initialization of my OpenGLES unit, Seems that just having the function laying around, even without calling it, causes the crash. Checking the android log, it says the following: E/AndroidRuntime(10684): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "TERRA_OPENGLES_$$_LOADOPENGL" referenced by "libterra.so"... LoadOpenGL() is the only pascal function that is contained in this unit (it just loads the opengles library dynamically and assigns function pointers). For some reason, adding the assembler function to this unit makes this function disappear, what causes this very weird behaviour? Full unit code here: http://pastebin.com/h2gCcikd Commenting both the function and the function call makes the game startup again without crashing (albeit still crashes whevener a float exception happens)

I've provided wrong code. Try this one:

procedure VFP_MaskExceptions; assembler; nostackframe; asm
.long 0xeef10a10 // fmrx r0,fpscr
bic r0,r0,#0x00001F00
.long 0xeee10a10 // fmxr fpscr,r0
end;

Show quoted text 6 lines
Probably recompiling FPC with hard float support would be the best solution, however compiling FPC in Windows is a frustrating game of trial and errors. I had written a .bat file that I used with 2.6.2, but it no longer works in 3.0.0. Once I have some free time I guess I will have to try discovering whats problem. Or if anyone has 3.0.1 compiled with hard-floats and can provide a download link, i would be thankful.

Building a cross compiler is a trivial task even on Windows. Read here ho to do that: http://wiki.freepascal.org/Android

Yury.

Reply by email

Sergio Flores
Building a cross compiler is a trivial task even on Windows. Read here ho to do that: http://wiki.freepascal.org/Android

I know how to build a crosscompiler, the problem is that doing it in Windows you sometimes get very weird errors (like the building process stopping with error message saying CreateProcess(null) failed without any other explanation) or the NDK linker just hangs.

Nevertheless I was now able to build FPC crosscompiler from the latest sources it with hard float support.
And now the compiled app crashes at startup with linking errors, saying it cant find my own functions in the library.
After investigating it, during the compilation some perfectly innocent functions are reporting invalid instructions (I dont have the log here, but it was instructions that started with Vsomething, if thats a clue). However a .a lib is still generated and the compilation ends with 'sucess'...

For the time I've returned to use the old crosscompiler I compiled myself with hard float support around 1 year ago, which works fine, with that I can run the app without any crashes.

I've read the link about the crosscompiler, I'm using the same compiler switches etc, all seems correct.
Maybe something in the ARM7 code generation got broken in the last months?

Reply by email

Yury Sidorov
to Sergio Flores
Sergio Flores wrote 7 lines
>Building a cross compiler is a trivial task even on Windows. >Read here ho to do that:http://wiki.freepascal.org/Android I know how to build a crosscompiler, the problem is that doing it in Windows you sometimes get very weird errors (like the building process stopping with error message saying CreateProcess(null) failed without any other explanation) or the NDK linker just hangs.

I've never experienced such issues. You should try to use different NDK versions. I use ndk-r8d. It is stable.

Nevertheless I was now able to build FPC crosscompiler from the latest sources it with hard float support. And now the compiled app crashes at startup with linking errors, saying it cant find my own functions in the library.

It's very weird.

Show quoted text 5 lines
After investigating it, during the compilation some perfectly innocent functions are reporting invalid instructions (I dont have the log here, but it was instructions that started with Vsomething, if thats a clue). However a .a lib is still generated and the compilation ends with 'sucess'...

Do you use static .a libs?

For the time I've returned to use the old crosscompiler I compiled myself with hard float support around 1 year ago, which works fine, with that I can run the app without any crashes.

The issue seems to be specific for your environment only. If you not try to find out the reason, it will never be fixed.

I've read the link about the crosscompiler, I'm using the same compiler switches etc, all seems correct. Maybe something in the ARM7 code generation got broken in the last months?

The 3.0 branch was created in January.

Yury.

Reply by email

Sergio Flores
I've never experienced such issues. You should try to use different NDK versions. I use ndk-r8d. It is stable.

I got the latest ndk download, it works fine, most of my problems were derived from using Mingw, switching to Cygwin solved the issues.

Do you use static .a libs?

I generate a .a lib that contains all pascal code, which is then loaded by java "dynamically" at the app startup. I'm not sure if there's other alternative approaches that allow mixing Java and Pascal in Android (I know how it possible to create a pure NDK app in Pascal, however lots of Java SDKs that I use that don't play well with that).

The issue seems to be specific for your environment only. If you not try to find out the reason, it will never be fixed.

Sure, I'll try again if I find some precompiled release with hard float support so I can understand better where the problem is. As for now, I'll keep using the old compiler, as it works fine and I don't need the new features that were introduced in 3.0.

Reply by email

Yury Sidorov
to Sergio Flores
Sergio Flores wrote
> I've never experienced such issues. You should try to use different NDK > versions. I use ndk-r8d. It is stable. I got the latest ndk download, it works fine, most of my problems were derived from using Mingw, switching to Cygwin solved the issues.

Actually there is no need to use mingw or needed
build tools are bundled with win32 fpc release. No extra tools are needed to build FPC from sources.

Show quoted text 6 lines
>Do you use static .a libs? I generate a .a lib that contains all pascal code, which is then loaded by java "dynamically" at the app startup. I'm not sure if there's other alternative approaches that allow mixing Java and Pascal in Android (I know how it possible to create a pure NDK app in Pascal, however lots of Java SDKs that I use that don't play well with that).

You build a dynamic .so library not a static .a library. You can not load a static library from Java.

Show quoted text 6 lines
>The issue seems to be specific for your environment only. If you not try > to find out the reason, it will never be fixed. Sure, I'll try again if I find some precompiled release with hard float support so I can understand better where the problem is. As for now, I'll keep using the old compiler, as it works fine and I don't need the new features that were introduced in 3.0.

I've performed more tests and found out that arm hard float exceptions are not handled at all in Android. It seems there is no need to mask them.

Looks like you have some installation issue. You can try to install FPC 3.0 on some clear system and build your library.

Yury.

Reply by email