In my app I have problem with floats on some Android based devices (ARM). Sometimes I see that my float has other value than which one I set before. I think that it may be caused by softfp (it's hard to reproduce this issue, because it appear in random situations - after 10 minute, next time after 3 minutes etc, but only for one variable). I don't see this issue on PC, so it looks like it's related to ARM and Android. I see that AngelScript doesn't support hard floating point on Android (as_config.h), but force softfp (AS_SOFTFP). Is it safe to force hard fp for AngelScript? Maybe it will solve my problem.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Problem with random float value on Android
AS_SOFTFP is just for the calling convention with native functions. You can't change this unless you also change the application to use HARDFP calling convention (which is not the standard on Android).
Whether the calling convention used is softfp or hardfp doesn't impact how floats are handled by the CPU itself. As far as I know all modern ARM CPUs have FPU, and the use of it would be turned on by default.
If I'd have to guess you're not having problem with softfp or hardfp itself (or else you would see the issue on all float values), Instead you're most likely being haunted by a memory invasion or something similar. The memory invasion is most likely present on PC too, but it could very well be harmless there depending on how memory is being allocated by the application.
If you can run your application on Linux/Mac I recommend using valgrind to try to detect the cause of this problem.
Author
Thanks for a replay. I can check my 64-bit linux binary in valgrind, however I never used it before, so maybe can you tell me which settings I should use for memcheck test? I tried valkyrie with default settings, but it shows only LDL problem with X64_CallFunction and a lot of fglrx_dri issues.
--- Update ---
Can you explain how this situation is interpreted by AngelScript (I found this issue in my script):
enum SOME_ENUM
{
TP0 = 0,
TP1,
TP2
}
for (uint i = 0; i < somebigvalue; ++i)
{
for (uint i = 0; i < objects[i].length(); ++i)
{
// 'i' is redeclared, so is it possible that it stores here values from range 0-somebigvalue?
int result = val[objects[i].getType()]; // objects[i].getType() return enum (SOME_ENUM).
problematicFloat = 0.5f * result;
}
}I currently replaced variable name in second 'for' and it looks like problem is gone, but I'm not sure thats why I'll thankful if you would comment this case.
Is it safe to use enums without casting to int as array ID eg. 'val[objects.getType()]' instead of 'val[int(objects.getType())]'? AngelScript compiler doesn't report any problems.
I normally use valgrind without any arguments, by default it will check for memory leaks and also access to unallocated memory.
The variable i in the inner loop should hide the variable i in the outer loop. However, I'll double check that this is actually happening, it might be that you've detected a bug.
Regardless of a potential bug in the compiler your script does look odd, and is probably not doing what you'd expect.
for (uint i = 0; i < objects[i].length(); ++i)
I imagine that with objects you actually intended to use the variable i from the outer loop, but the compiler will use the variable i from the inner loop in this case.
It is safe to use enums as integers. The enums are implicitly converted to ints as necessary.
Author
Valgrind with default settings doesn't show any memory problems, however I'll check it again with other settings tomorrow.
I imagine that with objects you actually intended to use the variable i from the outer loop, but the compiler will use the variable i from the inner loop in this case.
No, I need 'i' value from inner loop, so if variable from inner loop hide variable from outer loop my script works properly. It looks like I have to find my bug in other place :/ I'll post my results soon.
I'll be thankful about info (bug or not) with redeclared variables.
It's strange but only a few Android based devices are affected by this issue, thats why it's hard to debug and find it.
BTW. This app on iOS works without problems.
I'll be thankful about info (bug or not) with redeclared variables.
I'll see about adding a compiler warning for this.
iOS and Android is practically identical as far as AngelScript is concerned. There is just a minor difference in way function arguments are aligned (Android requires 64bit alignment for large types, whereas iOS uses 32bit alignment for all types). They both handle floats in the same way though.
Let me know if you find the root cause of the problem.
Author
I checked my app for memory leaks on iOS (instruments tool) and on Windows (visual leak detector) and both tools didn't find leaks, however after change NDK from r9 to r10 I still can't reproduce this issue on Android. At now I have following infos:
- This issue appeared with NDK r9x, however app builded with r10 wasn't tested too long ~5 hours.
- This issue didn't appear on CyanogenMod based devices. Maybe branded Android soft was fault (one Lenovo phone and one HTC as I remember).
I'll post more info when I'll get feedback from a beta testers.
Interesting.
I found this in the release notes for NDK r9c (Dec 2013):
- Fixed a problem with GCC 4.8 ARM, in which the stack pointer is restored too early. This problem prevented the frame pointer from reliably accessing a variable in the stack frame. (GCC Issue 58854)
It's impossible to know if it is actually related to the problem you're facing, but it does make it a little easier to believe the problem is actually caused by a bug in NDK r9.
Author
This problem still occur with NDK r10. I'll check armeabi-v7a build.
BTW. I tried to run my app with hard-float flag (of course I removed AS_SOFTFP in as_config.h for Android), but in this case AngelScript causes app crash (native calling convention), however with default settings for armeabi-v7a (softfp + fpu set to vfp3) AngelScript starts fine.
The code in as_callfunc_arm.cpp and as_callfunc_arm_gcc.S will probably need adjustments to support the hard-float ABI for Android. If you make the adjustments and tests I'll gladly incorporate them into the library.
AngelScript has only been tested with hard-float ABI for Linux. Although Android is pretty much Linux at its root, there is almost always some minor differences in the ABI.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
