Android crash when the Java code is calling a c++ callback

[jgranick]

#216 Issue by shoebox,

Hi Joshua,

Like we talked earlier i still have problems with native extensions & OpenFL 1.4 on Android targets.

I have reported the bug here, because i'm not sure if it's a openfl or hxcpp or NME bug...

I've setup a demo extension here: https://github.com/shoebox/demo-extension/ and a demo app who use the extension in the "demo" folder.

That extension first is passing to CPP the haxe callback method:
https://github.com/shoebox/demo-extension/blob/master/project/common/ExternalInterface.cpp#L36

Then after a delay, the java class call the CPP method, to dispatch a event back to haxe by calling the previously saved callback reference with a argument. (https://github.com/shoebox/demo-extension/blob/master/dependencies/android/src/org/haxe/extension/DemoJavaClass.java#L64) by using that cpp jni method: https://github.com/shoebox/demo-extension/blob/master/project/common/ExternalInterface.cpp#L47

And it crash:

E/hxcpp   (15722): GetLocalAllocMT - requesting memory from unregistered thread!                         
F/libc    (15722): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 15722 (d.demoextension)      

Those calls where working fine previously (more reliable than HaxeObject).

I tried to make the call from another thread, or the ui thread, but it still crash.

Thanks for your help,

Johann //

[jgranick]

Comment by kiroukou:

+1
Exact same problem here!

Quite bloking at the moment since most of our apps are extension based...
Since 1.4 they crash if we use the same technique as explained by Johann.

Would be really great if you can have a look Joshua ! :)
Thanks
Thomas

Le vendredi 9 mai 2014, Johann Martinache notifications@github.com a
écrit :

Hi Joshua,

Like we talked earlier i still have problems with native extensions &
OpenFL 1.4 on Android targets.

I have reported the bug here, because i'm not sure if it's a openfl or
hxcpp or NME bug...

I've setup a demo extension here:
https://github.com/shoebox/demo-extension/ and a demo app who use the
extension in the "demo" folder.

That extension first is passing to CPP the haxe callback method:

https://github.com/shoebox/demo-extension/blob/master/project/common/ExternalInterface.cpp#L36

Then after a delay, the java class call the CPP method, to dispatch a
event back to haxe by calling the previously saved callback reference with
a argument. (
https://github.com/shoebox/demo-extension/blob/master/dependencies/android/src/org/haxe/extension/DemoJavaClass.java#L64
)

And it crash:

E/hxcpp (15722): GetLocalAllocMT - requesting memory from unregistered thread!
F/libc (15722): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 15722 (d.demoextension)

Those calls where working fine previously (more reliable than HaxeObject).

Thanks for your help,

Johann //

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/216
.

[jgranick]

Comment by paala:

Openfl 2.0 has in release notes :..
Fixed issues in the Android JNI class
Is this issue solved?

[jgranick]

Comment by kiroukou:

Hi team.

It has been almost 2 months from the moment Shoebox reported that issue.
This is really blocking everyone using native extensions seriously, and as a consequence, companies trying to make commercial products with OpenFL.

This seems a little bit too low level for me to debug, and I have just no idea of what has been changed.

@jgranick do you have any idea ? Please just leave a word to let us know if that could be fixed soon or not, that we can plan what to do here :)

[jgranick]

Comment by hughsando:

Looks like you need to attach/detach the calling thread from the hxcpp runtime.
NME does this with the AutoHaxe object
https://github.com/haxenme/nme/blob/master/project/src/android/AndroidCommon.h#L19
like:
https://github.com/haxenme/nme/blob/master/project/src/android/AndroidFrame.cpp#L754

[jgranick]

Comment by hughsando:

Also note that you will need to be careful about which thread is used - if you call back from the ui thread, the haxe developer may not expect this - eg, they should not do any DisplayObject manipulation from anything other than the main haxe thread.

[jgranick]

Comment by shoebox:

I already tried previously to add the attach / detach thread, but it still crash

[jgranick]

Comment by hughsando:

So this:
GetLocalAllocMT - requesting memory from unregistered thread!
Is cerainly an attach/detach problem. The first step is to eliminate this. Now there might be a problem with reentrant callbacks or mismatching attach/detach calls. You can get some help here by uncommenting the debug statements in the AutoHaxe object.
The code you have linked does not have the attach calls, and it is certainly needed, so a first step would be to put a AutoHaxe object in. Maybe there is a second bug that make it appear previous attempts did not work.

[jgranick]

Comment by shoebox:

Need more tests, but the AutoHaxe seems to fix it !
Thanks a lot, it have been a frustating one !

That's the kind a breaking changes than we shoudl be notified (even if it's not that easy when it's so low level)

2 month of wait solved in 2hours :)

👍

[jgranick]

Comment by hughsando:

You have to pester me if I miss your first request - sometimes I zone out
and ignore emails. I wont be offended.

On Thu, Jul 3, 2014 at 7:55 PM, Johann Martinache notifications@github.com
wrote:

Need more tests, but the AutoHaxe seems to do the deed !
Thanks a lot, it have been a frustating one !

2 month of wait solved in 2hours ;)

—
Reply to this email directly or view it on GitHub
#216 (comment)
.

[jgranick]

Comment by shoebox:

Is there any thing of the sort to do on the iOS side ?

[jgranick]

Comment by kiroukou:

Will try this fix Hugh !
Thanks anyway to came here and help to sort it out that fast !

[jgranick]

Comment by hughsando:

IOS is much simpler because it all runs in the same thread.

On Thu, Jul 3, 2014 at 8:57 PM, kiroukou notifications@github.com wrote:

Will try this fix Hugh !
Thanks anyway to came here and help to sort it out that fast !

—
Reply to this email directly or view it on GitHub
#216 (comment)
.

[jgranick]

Comment by shoebox:

I had to remove the :
gc_exit_blocking()
//
gc_enter_blocking();

I just kept:
gc_set_top_of_stack(&top,true);

After that is seems to work on the iOS too.

[jgranick]

Comment by jgranick:

Is this a modification to OpenFL/NME somewhere, or is this in your extension? Thank you!

[jgranick]

Comment by shoebox:

It's on the extension side.

[jgranick]

Comment by paala:

So, what needs to be modified on your extensions in order to work with latest openFL?

[jgranick]

Comment by kiroukou:

I confirm that using AutoHaxe structure is working for us as well !

2014-07-07 9:33 GMT+02:00 paala notifications@github.com:

So, what needs to be modified on your extensions in order to work with
latest openFL?

—
Reply to this email directly or view it on GitHub
#216 (comment)
.