Loading external images crashes on android

Hello people,

I’m loading external images from my server and I noticed that on Android, twenty seconds( approx ) after the images get rendered, the app crash.

In flash builds this work perfectly but on Android crashes. For loading the external images I’m using a Loader ( openfl.display.Loader ) just like we used to do with AS3. I’m not using LoaderContexts and not allowing any secure domain( I’ts seems it’s not needed ) for doing this. I can successfully call *.php files and load the images which get rendered on the screen.

digging around with logcat I found this line:

Fatal signal 11 (SIGSEGV)

Googling this issue, I found that I needed to add:

<application android:allowClearUserData="true" ></application>

To my AndroidManifest.xml file in order to get rid of this problem. But I’m still getting the crash ¬¬’ so I wonder if using openfl.display.Loader is the best practice for getting an image from my server or there’s some other way to do it? Maybe creating an extension and loading the images from Java?

Have you guys experienced this issue before?

Thanks in advance,


Have you ruled out all other causes? There are a lot of things that can cause a segfault.

Does the log contain an info dump after the “Fatal signal 11” message? Because if so, the segfault is most likely caused by a null pointer. Fortunately, there are a couple ways to get a usable stack trace from it.

The easy way is to add these to project.xml:

<haxedef name="HXCPP_CHECK_POINTER" if="debug" />
<haxedef name="HXCPP_STACK_LINE" if="debug" />

With those enabled, you’ll get a useful error message whenever you try to access a pointer that’s null. (The if="debug" part is optional, but this really isn’t something you want in the final build.)

Thanks @player_03 . I added those haxedefs and launched my build. This is the log I get from the beginning and the end of the crash. Could you please point me a little what could be the cause of the problem, based on this log?

**--------- beginning of crash**

**F/libc    (11641): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x56c in tid 11641 (my_app)**

**I/DEBUG   (  278): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *****

**I/DEBUG   (  278): Build fingerprint: 'motorola/surnia_retla/surnia_umts:5.0.2/LXI22.50-53.8/12:user/release-keys'**

**I/DEBUG   (  278): Revision: 'p300'**

**I/DEBUG   (  278): ABI: 'arm'**

**I/DEBUG   (  278): pid: 11641, tid: 11641, name: my_app  >>> com.myappdomain.myappname <<<**

**I/DEBUG   (  278): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x56c**

**I/SFPerfTracer(  236):      triggers: (rate: 1849:91225) (compose: 18:730) (post: 394:16409) (render: 227:12586) (838:911347 frames) (839:977857)**

**I/DEBUG   (  278):     r0 0000006e  r1 a059e6dc  r2 0000056c  r3 0000006e**

**D/SFPerfTracer(  236):        layers: (2:10) (FocusedStackFrame (0xb816ca60): 0:6632)* (DimLayer (0xb819f048): 0:707)* (DimLayer (0xb81a1b70): 0:793)* (StatusBar (0xb81ad250): 2:42511)* (com.android.systemui.ImageWallpaper (0xb817ed18): 0:8217)* (NavigationBar (0xb81a99d0): 0:219) (com.myappdomain.myappname/com.myappdomain.myappname.MainActivity (0xb815d850): 0:27)* (SurfaceView (0xb8177818): 837:2156) **

**I/DEBUG   (  278):     r4 00000000  r5 a5f3ef58  r6 a059e74c  r7 a61be784**

**I/DEBUG   (  278):     r8 00000000  r9 a059e6dc  sl a059e584  fp 00007530**

**I/DEBUG   (  278):     ip a059e6a4  sp a059d720  lr a5f3f728  pc a5f3ef74  cpsr 80030010**

**I/DEBUG   (  278): **

**I/DEBUG   (  278): backtrace:**

**I/DEBUG   (  278):     #00 pc 000f5f74  /data/app/com.myappdomain.myappname-1/lib/arm/liblime.so**

**I/DEBUG   (  278):     #01 pc 000f6724  /data/app/com.myappdomain.myappname-1/lib/arm/liblime.so**

**I/DEBUG   (  278):     #02 pc 000f76cc  /data/app/com.myappdomain.myappname-1/lib/arm/liblime.so**

**I/DEBUG   (  278):     #03 pc 00100d90  /data/app/com.myappdomain.myappname-1/lib/arm/liblime.so**

**I/DEBUG   (  278):     #04 pc 000ea6c4  /data/app/com.myappdomain.myappname-1/lib/arm/liblime.so**

**W/ActivityManager(  792):   Force finishing activity com.myappdomain.myappname/.MainActivity**

**E/JavaBinder(  792): !!! FAILED BINDER TRANSACTION !!!**

**E/JavaBinder(  792): !!! FAILED BINDER TRANSACTION !!!**

**W/ActivityManager(  792): Exception thrown during pause**

**W/ActivityManager(  792): android.os.TransactionTooLargeException**

**W/ActivityManager(  792): 	at android.os.BinderProxy.transactNative(Native Method)**

**W/ActivityManager(  792): 	at android.os.BinderProxy.transact(Binder.java:496)**

**W/ActivityManager(  792): 	at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:708)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:858)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2782)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityStack.finishTopRunningActivityLocked(ActivityStack.java:2639)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityStackSupervisor.finishTopRunningActivityLocked(ActivityStackSupervisor.java:2500)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:11742)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:11639)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:12344)**

**W/ActivityManager(  792): 	at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:11840)**

**W/ActivityManager(  792): 	at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)**

**E/lowmemorykiller(  233): Error writing /proc/11641/oom_score_adj; errno=22**

**W/ContextImpl( 1475): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1455 android.content.ContextWrapper.sendBroadcast:376 com.motorola.motocare.util.TriggerHelper$TriggerBuilder.send:76 com.motorola.motocare.internal.frameworkevents.PauseResumeTrigger.handleFrameworkEvent:53 com.motorola.motocare.internal.frameworkevents.FwEventMonitor$FrameworkListener.processFrameworkEvent:114 **

**D/SFPerfTracer(  236):        layers: (4:12) (FocusedStackFrame (0xb816ca60): 0:6634)* (DimLayer (0xb816f518): 0:21)* (DimLayer (0xb819f048): 0:707)* (DimLayer (0xb81a1b70): 0:793)* (StatusBar (0xb81ad250): 1:42539) (com.android.systemui.ImageWallpaper (0xb817ed18): 0:8218) (NavigationBar (0xb81a99d0): 0:231) (com.myappdomain.myappname/com.myappdomain.myappname.MainActivity (0xb815d850): 0:27)- (SurfaceView (0xb8177818): 0:2156)- (Application Error: com.myappdomain.myappname (0xb8177818): 0:51)- (com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (0xb81b3fd0): 0:12)** 

( It’s was a huge log so I only left the parts that I considered relevant )

One thing that I forgot to mention is that it’s not necessary to add the images to the display list. Only loading them causes the issue to occur.



Can you reproduce this using an image off Google, and a standard sample (like the DisplayingABitmap sample)? Is this legacy? Thank you!

@singmajesty, I couldn’t reproduce it with the steps you proposed. I’m starting to suspect that is something happening in my app only. Could it be something related to out of memory errors? I’m trying to load about 10 pics.

soft versions:

openfl 3.4.0
hxcpp 3.2.193

Anyone has experienced this before? I don’t know which could be the cause of the problem. Is There any other useful haxedefs for adding more info to the output?

Not if the problem happens in lime.so (which it apparently does). Haxedefs in project.xml only affect ApplicationMain.so.

If you want to get the stack trace, you’ll have to recompile lime.so with the defines I mentioned. This isn’t an easy task, and I don’t know the details beyond the fact that you’ll have to download the Git version of Lime.

I asked a friend which is an Android dev and he noticed this line

W/ActivityManager( 792): android.os.TransactionTooLargeException

After telling him that haxe runs on the UI thread and get scolded by him :scream: :joy: he told me that we shouldn’t being loading things on the UI thread because we can get that excepction, which will throw an error popup and force the application to exit.

So, is openfl.display.Loader making its work on the UI thread? Someone tested what should happen loading a bunch of images? Maybe the problem is in there

I think that the Haxe code runs on a GL thread, but Loader may be generating new threads. Do you load all images at once, or one at a time? I wonder if this is a max threads type issue

We have a class with accepts an array of URLs to load, then we create a loader for each one, we push it to an Array of loaders and we start the load. We wait for all the pics to be loaded and then we return them.

All this work happens inside a “for” loop so it’s like we are requesting the images at once, with different loaders.

If you’d like to see it happens in a modified OpenFL sample, that would be really useful. See if we can break it outside your project to see if its related :slight_smile:

Hi everyone,
My problem :
04-26 10:51:36.203 4736-4754/? A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x7c in tid 4754 (GLThread 4937)
04-26 10:51:37.023 1748-1748/? E/audit: type=1701 msg=audit(1461642697.023:246): auid=4294967295 uid=10560 gid=10560 ses=4294967295 subj=u:r:untrusted_app:s0 pid=4754 comm=474C5468726561642034393337 reason=“memory violation” sig=11

can you tell me about this error :frowning: Thank you!

Try building lime.so with -DHXCPP_DEBUG_LINK.
At least you can locate where problem is occurring from backtrace.

I want lime to include libraries with full debug information, so that developers don’t need to build lime from source when they debug it.

thank for your help :slight_smile: