Android (x86) app closes after a few seconds running fine with SIGSEV #8256

wombatstampede · 2017-04-04T10:13:33Z

Hi all!
I verified this with my "normal" app as well as with a minimum app only consisting of 1 label.
The segmentation fault only occurs when the app is exported with x86 support (and ARM). w/o x86 support it runs fine but much slower.

Godot version: 2.1.2.stable.official
Android version: 4.3 Jellybean (Device: Asus ME302C, 2GB RAM, dual core intel processor)

I get that error only on the X86 Device. It runs fine if I run the app in an emulator on an x86 PC.

Visible Error:
App starts and runs normal. But closes after around 10 seconds.

Some part of the dump:

03-31 12:34:21.390 10977 10990 F libc    : Fatal signal 11 (SIGSEGV) at 0x00000000 (code=128), thread 10990 (Thread-1485)
03-31 12:34:21.440 23186 23186 I DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-31 12:34:21.440 23186 23186 I DEBUG   : Build fingerprint: 'asus/WW_epad/ME302C:4.3/JSS15Q
WW_epad-V5.0.21-20140701:user/release-keys'
03-31 12:34:21.440 23186 23186 I DEBUG   : Revision: '0'
03-31 12:34:21.440 23186 23186 I DEBUG   : pid: 10977, tid: 10990, name: Thread-1485  >>> org.godotengine.narrowbotsimulator <<<
03-31 12:34:21.440 23186 23186 I DEBUG   : signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 00000000
03-31 12:34:21.530 23186 23186 I DEBUG   :     eax 00000000  ebx 7a10facc  ecx 0039393f  edx 00000000
03-31 12:34:21.530 23186 23186 I DEBUG   :     esi 000041b0  edi 00000000
03-31 12:34:21.530 23186 23186 I DEBUG   :     xcs 00000073  xds 0000007b  xes 0000007b  xfs 00000000  xss 0000007b
03-31 12:34:21.530 23186 23186 I DEBUG   :     eip 78f87167  ebp 0039393f  esp 7a4f590c  flags 00210246
03-31 12:34:21.540 23186 23186 I DEBUG   : 
03-31 12:34:21.540 23186 23186 I DEBUG   : backtrace:
03-31 12:34:21.540 23186 23186 I DEBUG   :     #00  pc 00087167  /data/app-lib/org.godotengine.narrowbotsimulator-2/libgodot_android.so (Main::iteration()+119)
03-31 12:34:21.540 23186 23186 I DEBUG   :     #01  pc 00050f81  /data/app-lib/org.godotengine.narrowbotsimulator-2/libgodot_android.so (OS_Android::main_loop_iterate()+33)
03-31 12:34:21.540 23186 23186 I DEBUG   :     #02  pc 0005e083  /data/app-lib/org.godotengine.narrowbotsimulator-2/libgodot_android.so (Java_org_godotengine_godot_GodotLib_step+3443)
03-31 12:34:21.540 23186 23186 I DEBUG   :     #03  pc 0007c24f  /system/lib/libdvm.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #04  pc 00000e0f  <unknown>
03-31 12:34:21.540 23186 23186 I DEBUG   :     #05  pc 000d7dfc  /system/lib/libdvm.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #06  pc 00000118  /dev/ashmem/dalvik-jit-code-cache (deleted)
03-31 12:34:21.540 23186 23186 I DEBUG   :     #07  pc 0008cd61  /system/lib/libdvm.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #08  pc 0010abbe  /system/lib/libdvm.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #09  pc 0010af17  /system/lib/libdvm.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #10  pc 000e8e2a  /system/lib/libdvm.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #11  pc 0001b55c  /system/lib/libc.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #12  pc 0003dcb5  /system/lib/libc.so
03-31 12:34:21.540 23186 23186 I DEBUG   :     #13  pc 000e8a7f  /system/lib/libdvm.so

If I understood this right (my android dev knowledge is very limited) that error presumably occured here:


	if (frame > 1000000) {
		if (GLOBAL_DEF("debug/stdout/print_fps", OS::get_singleton()->is_stdout_verbose())) {
			print_line("FPS: " + itos(frames));
		};
		Engine::get_singleton()->_fps = frames; //******here?*******
		performance->set_process_time(USEC_TO_SEC(idle_process_max));
		performance->set_fixed_process_time(USEC_TO_SEC(fixed_process_max));
		idle_process_max = 0;
		fixed_process_max = 0;

		frame %= 1000000;
		frames = 0;
	}

Funny thing is you declare "frames" in main.cpp as uint32:
uint32_t Main::frames = 0;

And in engine.h as float:
float _fps;

Could that case the problem in x86 code that you set a float with an int? Or did I get this wrong?

The text was updated successfully, but these errors were encountered:

RandomShaper · 2017-04-05T15:16:45Z

Does the crash always happen at the same location if you run your project a number of times in a row? The same location regardless which project you try?

Of course, by location I mean the #00 entry of the backtrace.

wombatstampede · 2017-04-05T16:50:00Z

I can surely tell that it is happening for the same project at exactly the same row (in Main::iteration())

I didn't log for the test project,yet. I'll post again when I have. (The device is usually not near my dev. PC)

b.t.w. float and uint32 both have usually the same size (4bytes) but I wonder that the compiler doesn't throw an error at that line (or I understood something wrong)

RandomShaper · 2017-04-05T17:02:45Z

Well, the compiler wouldn't generate invalid code because of that. If there is a type conversion available, it will perform it; else, it will throw an error.

Are you running the debug or release variant? (One-click-deploy is debug as well.)

wombatstampede · 2017-04-05T18:50:02Z

I am running the debug variant.
I now checked with the test app (only consisting of a single hello world label). Error occured on same location.


4-05 20:22:32.340   452   468 I ActivityManager: Displayed org.godotengine.androidtest/org.godotengine.godot.Godot: +573ms
04-05 20:22:32.500  1622  1635 I godot   : OpenSL Init OK!
04-05 20:22:37.000   146   146 I DEBUG   : pid: 1622, tid: 1635, name: Thread-2742  >>> org.godotengine.androidtest <<<
04-05 20:22:37.600   146   146 I DEBUG   :     #00  pc 00087167  /data/app-lib/org.godotengine.androidtest-1/libgodot_android.so (Main::iteration()+119)
04-05 20:22:37.600   146   146 I DEBUG   :     #01  pc 00050f81  /data/app-lib/org.godotengine.androidtest-1/libgodot_android.so (OS_Android::main_loop_iterate()+33)
04-05 20:22:37.600   146   146 I DEBUG   :     #02  pc 0005e083  /data/app-lib/org.godotengine.androidtest-1/libgodot_android.so (Java_org_godotengine_godot_GodotLib_step+3443)

RandomShaper · 2017-04-05T18:54:43Z

Thank you. That information is useful.

RandomShaper · 2017-04-05T20:27:09Z

I think my PR fixes the issue.

If you don't know-how/want to build yourself, you'll have to wait to 2.1.3 or try on a device with Android 5.0 or higher.

By the way, the Android version that your testing emulator runs is 5.0 at least, isn't it?

wombatstampede · 2017-04-10T08:08:40Z

Sorry for the late reply.
Thank you! That fix really looks like it will correct the x86 android issue. I have found no time to set up a build environment for the android template, yet and the publically available "nightly" builds seem to spare out the android template due to build errors. (probably on their side)

I'll test & tell when the next RC arrives.

The android version on the emulator was 4.1.1 b.t.w. :-) Doesn't quite fit but perhaps it just worked by chance (as many software products).

akien-mga · 2017-04-10T08:18:48Z

@wombatstampede Those binaries include the android templates: http://download.tuxfamily.org/godotengine/2.1.3/rc2/

wombatstampede · 2017-04-10T09:58:37Z

Thank you akien-mga, I wasn't aware of the RC2 release, yet.

It works! (So I confirm the the bug doesn't show anymore on that device)

bojidar-bg · 2017-04-10T09:59:20Z

Closing as fixed then...

RandomShaper · 2017-04-10T18:14:32Z

Thank you for the update. ¿4.1.1?, hmm... I guess the emulator is somehow more resilient to misalignment. Is your x86 emulator running with HAXM or without it? The latter would be an explanation since a software-emulated CPU wouldn't need to enforce that (although it wouldn't then be accurately emulating...). Anyway, the former may also have some countermeasure. Well, just out of curiosity. El 10/04/2017 a las 10:08, wombatstampede escribió:

…

Sorry for the late reply. Thank you! That fix really looks like it will correct the x86 android issue. I have found no time to set up a build environment for the android template, yet and the publically available "nightly" builds seem to spare out the android template due to build errors. (probably on their side) I'll test & tell when the next RC arrives. The android version on the emulator was 4.1.1 b.t.w. :-) Doesn't quite fit but perhaps it just worked by chance (as many software products). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8256 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALQCtqWOhhQt4zYKmv1mNfm7ReZX8Wk9ks5rueOVgaJpZM4Mypo5>.

wombatstampede · 2017-04-17T12:55:53Z

Hi RandomShaper,
the emulator is (AFAIK) not using HAXM. It is based on Oracle Virtual Box (Genymotion).

But I'm unsure about "software-emulated CPU" since the emu is running on a x86 (Intel i5) and the emulated android is using x86 as well.

RandomShaper · 2017-04-17T15:25:09Z

Thank you for the information. I can't make a conclusion out of it, but I guess it's time to stop thinking on this subject. :) El 17 abr. 2017 2:56 p. m., "wombatstampede" <notifications@github.com> escribió:

…

Hi RandomShaper, the emulator is (AFAIK) not using HAXM. It is based on Oracle Virtual Box (Genymotion). But I'm unsure about "software-emulated CPU" since the emu is running on a x86 (Intel i5) and the emulated android is using x86 as well. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8256 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALQCts15I5vdKF4mXN5r50DX_tL9hELXks5rw2FmgaJpZM4Mypo5> .

akien-mga added bug platform:android topic:porting labels Apr 4, 2017

akien-mga added this to the 2.1 milestone Apr 4, 2017

akien-mga changed the title ~~(Godot 2.1.2) Android (x86) app closes after a few seconds running fine with SIGSEV~~ Android (x86) app closes after a few seconds running fine with SIGSEV Apr 4, 2017

RandomShaper mentioned this issue Apr 5, 2017

Fix crash on Android-x86 (2.1) #8273

Merged

bojidar-bg closed this as completed Apr 10, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Android (x86) app closes after a few seconds running fine with SIGSEV #8256

Android (x86) app closes after a few seconds running fine with SIGSEV #8256

wombatstampede commented Apr 4, 2017 •

edited

Loading

RandomShaper commented Apr 5, 2017

wombatstampede commented Apr 5, 2017

RandomShaper commented Apr 5, 2017

wombatstampede commented Apr 5, 2017

RandomShaper commented Apr 5, 2017

RandomShaper commented Apr 5, 2017 •

edited

Loading

wombatstampede commented Apr 10, 2017

akien-mga commented Apr 10, 2017

wombatstampede commented Apr 10, 2017

bojidar-bg commented Apr 10, 2017

RandomShaper commented Apr 10, 2017 via email

wombatstampede commented Apr 17, 2017

RandomShaper commented Apr 17, 2017 via email

Android (x86) app closes after a few seconds running fine with SIGSEV #8256

Android (x86) app closes after a few seconds running fine with SIGSEV #8256

Comments

wombatstampede commented Apr 4, 2017 • edited Loading

RandomShaper commented Apr 5, 2017

wombatstampede commented Apr 5, 2017

RandomShaper commented Apr 5, 2017

wombatstampede commented Apr 5, 2017

RandomShaper commented Apr 5, 2017

RandomShaper commented Apr 5, 2017 • edited Loading

wombatstampede commented Apr 10, 2017

akien-mga commented Apr 10, 2017

wombatstampede commented Apr 10, 2017

bojidar-bg commented Apr 10, 2017

RandomShaper commented Apr 10, 2017 via email

wombatstampede commented Apr 17, 2017

RandomShaper commented Apr 17, 2017 via email

wombatstampede commented Apr 4, 2017 •

edited

Loading

RandomShaper commented Apr 5, 2017 •

edited

Loading