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:
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 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.
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?
@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.
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.
After telling him that haxe runs on the UI thread and get scolded by him 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
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.
Thank you!