GetLocalAllocMT - requesting memory from unregistered thread!

[kevinresol]

Was trying to use threads in an app. It works fine on mac/windows/iphone but on android I get an error GetLocalAllocMT - requesting memory from unregistered thread! when pressing "home" button while a thread (non-main) is active.

duplicate from: snowkit/snow#79

[hughsando]

I need a bit more information, like a call-stack, to work out if this is a hxcpp problem or a snow problem.
My guess is that the app is responding to some kind of "app pause" callback (which occurs on the gui thread) without calling the AutoHaxe or SetTopOfStack functions.

[kevinresol]

how to obtain the call-stack? because currently the app just crashes with this one line of log in the android logcat

[hughsando]

This is supposed to get the OS to dump something - like a java callstack on android.
You could try adding a 'criticalerror' in Immix.cpp, like:

void BadImmixAlloc()
{
   hx::CriticalError(HX_CSTRING("Bad local allocator"));
  ...

Which might give some better info.
Otherwise, Sven might know the general sequence that is invoked by the home button.

[kevinresol]

Hm... adding the line in Immix.cpp doesn't seem to give something useful...

[kevinresol]

Followed the guide here, not sure if it is even useful.....

Maybe relavant: https://github.com/underscorediscovery/snow/blob/master/flow/android/src/org/libsdl/app/SDLActivity.java#L374

[kevinresol]

[kevinresol]

up?

[hughsando]

I'm working on the assumption that this is a snow error - that is, libsnow is making haxe calls from a non-haxe thread, and the hxcpp response is legitimate.
If Sven at snowkit thinks differently, I will have another look.

[kevinresol]

@hughsando thanks for the information, I would like to investigate the problem further too, as Sven maybe too busy to do so. However, would you please give me some hints on what's happening behind the scene? Since it seems that it is crashing right inside the SDL nativePause method, which should have nothing with haxe.
So, may I have some hints like: are there anything should be done before calling SDL nativePause?

cc. @underscorediscovery snowkit/snow#79

[hughsando]

If SDL nativePause is anything like the NME case, it will be being called
from the android UI thread.
Most of the other stuff is usually called from the main haxe thread, which
is the "renderThread".
Typically, the java code calls into the native code, (libsnow) which then
looks up some kind of handler object that was created by haxe, and calls
something on it. Nme does this:
https://github.com/haxenme/nme/blob/master/project/src/android/AndroidFrame.cpp#L878
This would typically call an object you defined or inherited in haxe in
your libCenacle library.
My guess is that the libsnow code is not using something like the
"AutoHaxe" object in this case (although must be using something similar in
other cases), which is what attaches and unattaches the haxe thread.
So if you follow the logic from the java into libsnow via a JNI call like
"JAVA_EXPORT int JNICALL Java_.....app_SDLActivity_nativePause" you should
see it calling (eventually) a haxe-defined object. See what is different
about this call, rather than say the "render" call.

On Tue, Nov 17, 2015 at 12:52 PM, Kevin Leung [email protected]
wrote:

@hughsando https://github.com/hughsando thanks for the information, I
would like to investigate the problem further too, as Sven maybe too busy
to do so. However, would you please give me some hints on what's happening
behind the scene? Since it seems that it is crashing right inside the SDL
nativePause
https://github.com/underscorediscovery/snow/blob/master/flow/android/src/org/libsdl/app/SDLActivity.java#L374
method, which should have nothing with haxe.
So, may I have some hints like: are there anything should be done before
calling SDL nativePause?

cc. @underscorediscovery https://github.com/underscorediscovery
snowkit/snow#79
snowkit/snow#79

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

[ruby0x1]

I'm back this week to have a closer look, and will reply with some debugging suggestions in the snow thread.

[ruby0x1]

(You can close this issue, as it relates specifically to snow)