search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
203 stars 11 forks source link

AIR SDK 33.1.1.856 - java.lang.OutOfMemoryError: PushLocalFrame #1950

Open takazawa-gg opened 2 years ago

takazawa-gg commented 2 years ago

Hi I'm annoyed because I get the following PushLocalFrame error with a specific app and a specific device combination. I want you to help me...

2022-06-02 14:52:22.326 21453-21453/? W/zygote64: Throwing OutOfMemoryError "PushLocalFrame"
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016] No pending exception expected: java.lang.OutOfMemoryError: PushLocalFrame
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.Entrypoints.EntryMainWrapper(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object, boolean, boolean) (Entrypoints.java:-2)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.Entrypoints.EntryMain(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object, boolean, boolean) (Entrypoints.java:143)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.AndroidActivityWrapper.LaunchApplication(android.app.Activity, com.adobe.air.AIRWindowSurfaceView, java.lang.String, java.lang.String, java.lang.String, boolean, boolean) (AndroidActivityWrapper.java:1235)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.AndroidActivityWrapper.launchApplication() (AndroidActivityWrapper.java:1523)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.AndroidActivityWrapper.onSurfaceInitialized() (AndroidActivityWrapper.java:1509)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.AIRWindowSurfaceView.surfaceChanged(android.view.SurfaceHolder, int, int, int) (AIRWindowSurfaceView.java:802)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.SurfaceView.updateSurface() (SurfaceView.java:766)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at boolean android.view.SurfaceView$2.onPreDraw() (SurfaceView.java:154)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at boolean android.view.ViewTreeObserver.dispatchOnPreDraw() (ViewTreeObserver.java:1045)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.ViewRootImpl.performTraversals() (ViewRootImpl.java:2800)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.ViewRootImpl.doTraversal() (ViewRootImpl.java:1779)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.ViewRootImpl$TraversalRunnable.run() (ViewRootImpl.java:7810)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.Choreographer$CallbackRecord.run(long) (Choreographer.java:911)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.Choreographer.doCallbacks(int, long) (Choreographer.java:723)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.Choreographer.doFrame(long, int) (Choreographer.java:658)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.view.Choreographer$FrameDisplayEventReceiver.run() (Choreographer.java:897)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.os.Handler.handleCallback(android.os.Message) (Handler.java:789)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.os.Handler.dispatchMessage(android.os.Message) (Handler.java:98)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.os.Looper.loop() (Looper.java:164)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void android.app.ActivityThread.main(java.lang.String[]) (ActivityThread.java:6938)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at java.lang.Object java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) (Method.java:-2)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.android.internal.os.Zygote$MethodAndArgsCaller.run() (Zygote.java:327)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.android.internal.os.ZygoteInit.main(java.lang.String[]) (ZygoteInit.java:1374)

The app crashes after launching the app and displaying the splash screen. I wrote trace at the beginning of the constructor of the entry point class (Main.as), but it seems to crash before the log is output.

I've tried it on multiple Android devices, some devices get the error and some don't.

Development environment

Devices where the error occurs

Devices that did not cause an error

Another app built under the same conditions will work fine on the device where the error occurs. The common points are as follows.

I don't think it's a problem that depends on the content of the app, as the logic of the app crashed before it started working. However, since the development environment and the version of the tool used are the same, I do not understand why some apps do not cause an error...

Can you find the problem from logcat? Attach the logs when the exception occurred and when it did not.

Thanks.

takazawa-gg commented 2 years ago

I've tried it with the new 33.1.1.889 and it still has this problem.

a9848840 commented 2 years ago

I have the same problem

use AirSdk:33.1.1.889 asus:ZenPad android:7

07-12 17:04:16.840 19142 19142 W art : Throwing OutOfMemoryError "PushLocalFrame" 07-12 17:04:16.840 19142 19142 E art : JNI ERROR (app bug): accessed stale local reference 0x2007d1 (index 500 in a table of size 500) 07-12 17:04:16.840 19142 19142 F art : art/runtime/indirect_reference_table.cc:66] JNI ERROR (app bug): see above. 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] Runtime aborting... 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] Aborting thread: 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] "main" prio=7 tid=1 Runnable 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] | group="" sCount=0 dsCount=0 obj=0x74cddaf0 self=0x7f97e96a00 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] | sysTid=19142 nice=-4 cgrp=default sched=0/0 handle=0x7f9bd27a98 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] | state=R schedstat=( 29334802273 744485221 8719 ) utm=2711 stm=222 core=4 HZ=100 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] | stack=0x7fec901000-0x7fec903000 stackSize=8MB 07-12 17:04:17.231 19142 19142 F art : art/runtime/runtime.cc:403] | held mutexes= "abort lock" "mutator lock"(shared held)

//===========================

I found the reason for triggering ERR Because there is a list image and the text field is too long leave a record here

//===========================

I changed the text field to the default font, then my problem was solved

ajwfrost commented 2 years ago

Hi @takazawa-gg - I've just looked at the log for one of the non-working scenarios, this is causing a problem at start-up itself:

2022-06-02 14:52:22.224 21453-21597/? D/TenjinStartup: Starting advertising id retrieval
2022-06-02 14:52:22.224 21453-21598/? D/TenjinStartup: Starting attribution retrieval
2022-06-02 14:52:22.224 21453-21597/? D/Tenjin: Attempting ad id retrieval, will retry 3 more times
2022-06-02 14:52:22.225 21453-21599/? D/AttributionParams: Request PlayStore install referrer
2022-06-02 14:52:22.225 21453-21599/? D/Tenjin: Attempting to retrieve Play Store referral info, attempt 01
2022-06-02 14:52:22.227 21453-21600/? D/AttributionParams: Request Huawei App Gallery install referrer
2022-06-02 14:52:22.227 21453-21600/? D/HuaweiInstallReferrer: Attempting to retrieve Huawei referral info, attempt 0
2022-06-02 14:52:22.228 21453-21600/? E/TenjinReflection: Error running static method newBuilder on com.huawei.hms.ads.installreferrer.api.InstallReferrerClient : com.huawei.hms.ads.installreferrer.api.InstallReferrerClient
2022-06-02 14:52:22.240 21453-21453/? D/com.distriqt.IDFA: IDFAController::getIDFA()
2022-06-02 14:52:22.242 21453-21453/? D/com.distriqt.IDFA: IDFAController::Google Play services is available.
2022-06-02 14:52:22.326 21453-21453/? W/zygote64: Throwing OutOfMemoryError "PushLocalFrame"
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016] No pending exception expected: java.lang.OutOfMemoryError: PushLocalFrame
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.Entrypoints.EntryMainWrapper(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object, boolean, boolean) (Entrypoints.java:-2)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.Entrypoints.EntryMain(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object, boolean, boolean) (Entrypoints.java:143)
2022-06-02 14:52:22.331 21453-21453/? A/zygote64: thread.cc:2016]   at void com.adobe.air.AndroidActivityWrapper.LaunchApplication(android.app.Activity, com.adobe.air.AIRWindowSurfaceView, java.lang.String, java.lang.String, java.lang.String, boolean, boolean) (AndroidActivityWrapper.java:1235)

This is quite an odd scenario because we're still in the LaunchApplication call i.e. the initial loading of the SWF file, we've probably not left the constructor for the main ActionScript class (if we've even entered it). I'm wondering what all that extension stuff is doing, although afaik it wouldn't be using JNI. The error about PushLocalFrame and out-of-memory implies that we have a lot of Java objects referenced within a single call frame which - unless the ANEs are using C/C++ - would imply calls into the AIR runtime are triggering more and more references.

The native part of the call stack should help:

2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #09 pc 000000000031145c  /system/lib64/libart.so (_ZN3art3JNI9FindClassEP7_JNIEnvPKc+1432)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #10 pc 0000000000280ef0  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #11 pc 00000000002e4b54  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #12 pc 00000000002e4ad8  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #13 pc 000000000027c998  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #14 pc 00000000003e3cf4  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #15 pc 00000000005a533c  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)
2022-06-02 14:52:22.406 21453-21453/? A/zygote64: runtime.cc:514]   native: #16 pc 00000000005e9e1c  /data/app/air.jp.globalgear.kura-Hrw_H0SjhLI1D7M8rvJO-g==/lib/arm64/libCore.so (???)

and actually this appears to show the creation of BitmapData objects that are backed by a Java bitmap. It looks like the full call stack may not be present there but I would hazard a guess that this is related to fonts/text and the way in which text is being rendered. Do you have a lot of test fields, or text appearing in the first frame? How do you render this, are you using Stage3D and Starling/Feathers/etc or is it classic text fields etc?

And do you have any setting in your application descriptor file for <newFontRenderingFromAPI>? I would suggest omitting it so that it only kicks in on the newer devices where you're not seeing any errors..

thanks

takazawa-gg commented 2 years ago

Hi @ajwfrost, thanks for answering my query.

First I am wondering if some sort of threshold regarding PushLocalFrame and out-of-memory has changed between AIR SDK 33.1.1.575 and 33.1.1.856(889)? Or could it be due to Android SDK differences or some other factor?

I'm wondering what all that extension stuff is doing, although afaik it wouldn't be using JNI.

The Tenjin extension that appears in this log is used to measure the effectiveness of advertising campaigns.

I am using this SDK to create ANE. https://github.com/tenjin/tenjin-android-sdk

Tenjin appears to use an installation referrer and some communication to the server, but these are light processes. Also, there are some error-like indications in the logs, but these are not actual problems and can be ignored. Probably not making many calls to many runtimes, but I don't know the details.

If there is a problem here, this should probably be the same for all other apps that use the same library and AndroidManifest template.

The other com.distriqt.IDFA that comes up is from Distriqt and uses version 5.0.028.

Do you have a lot of test fields, or text appearing in the first frame? How do you render this, are you using Stage3D and Starling/Feathers/etc or is it classic text fields etc?

How exactly should "first frame" be checked?

We have placed the first screen part of the app in a MovieClip with a Linkage called TitleScene, and after Main.as is loaded, the TitleScene is new and addChild for display.

The TitleScene has some complex animations, so there are about 50 MovieClips in total that are placed. The title text is also placed, but it is not a TextField, but an image of the designed text. It is not a rendering of Font. Stage3D and Starling/Feathers/etc. are also not used.

But TitleScene may have a lot of elements, but I don't think it matters because it is loaded after Main.as, so it crashes before that….

If needed, we can provide our fla or project if you provide a closed upload environment.

And do you have any setting in your application descriptor file for ?

No, to my knowledge is not used.

Thanks.

ajwfrost commented 2 years ago

Thanks for the details

First I am wondering if some sort of threshold regarding PushLocalFrame and out-of-memory has changed between AIR SDK 33.1.1.575 and 33.1.1.856(889)?

I'm not sure about thresholds but there are changes to how we'd doing some of the rendering between these builds. Originally, AIR used a private version of skia to do some of the drawing, but this then ended up with incompatibilities around the font handling so we had to switch to use the public APIs, which we're accessing via JNI. And this is where the 'PushLocalFrame' thing comes in, where we're creating/keeping local references to Java objects from JNI. The implication is that there are 500 different Java objects that we're referencing and this is as many as it can count..

I think either we've got a problem in the code where we're not releasing references in a timely manner, causing this value to increase; or we really do need to have more than 500 references, which means we will need to change how we manage/store these references..

We've created a test build that has some extra debug generated via logcat, would you be able to unzip the below file and put it into the SDK folder under "runtimes\air\android\device\arm8"? Then if you package up your app (with -arch armv8) and run the same thing, hopefully there will be a bunch of traces with a tag of "AdobeAIR_JNI" that we can look at to see what's happening..?

thanks

Runtime.zip

a9848840 commented 2 years ago

When I initialized the game scene interface, I encountered this problem PushLocalFrame, and it must happen

my other game scene has many pictures and a lot of text fields I changed the text field to the default font. Happening now

happened at android 7 android 8

PushLocalFrame.txt

ajwfrost commented 2 years ago

Hi @a9848840 - can you confirm which build you used to get that PushLocalFrame.txt logcat output? it doesn't have the app start-up information in it so I can't see which version it is... (if you're able to try it again with the runtime.apk from the above zip file, it would be useful...)

thanks

a9848840 commented 2 years ago

i use AIR SDK 33.1.1.856

runtime.zip Please give me some time ><

ajwfrost commented 2 years ago

Thanks - so if that's the 856 build then the stack trace shows we're measuring some text at the point at which it runs out of local JNI handles...

ajwfrost commented 2 years ago

Actually, looking again at the call stack/error there, this may be something different? (or related?)

07-22 15:01:30.861 23133 23133 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 23133 (winner.bwmj16tw)
07-22 15:01:31.016 23535 23535 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
07-22 15:01:31.031 23535 23535 F DEBUG   : Abort message: 'art/runtime/indirect_reference_table.cc:66] JNI ERROR (app bug): see above.'
07-22 15:01:31.047 23535 23535 F DEBUG   :     #08 pc 000000000044f2cc  /system/lib64/libart.so (_ZNK3art6Thread13DecodeJObjectEP8_jobject+80)
07-22 15:01:31.047 23535 23535 F DEBUG   :     #09 pc 000000000042704c  /system/lib64/libart.so (_ZN3art8ArgArray24BuildArgArrayFromJValuesERKNS_33ScopedObjectAccessAlreadyRunnableEPNS_6mirror6ObjectEP6jvalue+220)
07-22 15:01:31.047 23535 23535 F DEBUG   :     #10 pc 0000000000427208  /system/lib64/libart.so (_ZN3art35InvokeVirtualOrInterfaceWithJValuesERKNS_33ScopedObjectAccessAlreadyRunnableEP8_jobjectP10_jmethodIDP6jvalue+348)
07-22 15:01:31.047 23535 23535 F DEBUG   :     #11 pc 00000000003307c8  /system/lib64/libart.so (_ZN3art3JNI15CallVoidMethodAEP7_JNIEnvP8_jobjectP10_jmethodIDP6jvalue+608)
07-22 15:01:31.047 23535 23535 F DEBUG   :     #12 pc 00000000002f2a38  /data/app/air.tw.com.bonuswinner.bwmj16tw-1/lib/arm64/libCore.so

So what's happening here is a call to the Android Paint.getTextBounds(String, int, int, Rect) and it's crashing perhaps when looking at one of the arguments... we can check this.

And then later on you have the "OutOfMemory" error with PushLocalFrame. But that's a different process.. and there are some audio warnings coming out here:

07-22 16:17:33.529 26776 31299 W AudioTrack: releaseBuffer() track 0x7f33380800 disabled due to previous underrun, restarting

so I'm wondering whether it may be audio-related rather than text-related. Would be interesting to know if other folk are also using audio/sound tracks?

thanks

KupoGames commented 2 years ago

Here's my logcat when I try to launch air.EpicBattleFantasy5 on an Android 8 Galaxy Note8, using the debug runtime. If it's helpful, I can also get the logcat from a newer Android 12 device.

899 debug runtime.txt

ajwfrost commented 2 years ago

Great, thanks - that's fine for now, what we'll probably do is make a few tweaks based on this and also add a little more targeted output, to try to narrow things down more...

The main parts that are repeating a lot:

07-22 12:20:58.584 20953 20953 D AdobeAIR_JNI: Creating surface/image for bitmaps 134x124 16641 5063
07-22 12:20:58.584 20953 20953 D AdobeAIR_JNI: Creating surface/image in surface update 134x124 16641 7258

so we'll look at (a) whether we need to actually have these ones backed by a Java bitmap, and (b) whether we can ensure the number of local references is kept down...

ajwfrost commented 2 years ago

Next version to try out is below please! Many thanks :-) Runtime.zip

takazawa-gg commented 2 years ago

Hi @ajwfrost

I built with the two Runtime.apk's I received.

First, here are the logs as of the 07/22 14:45 version.

Next is the log as of 07/22 23:22 version.

The crash did not occur in this version. Does this mean that the fix for the Java bitmap handling worked? If so, great!

a9848840 commented 2 years ago

hi @ajwfrost

2nd Runtime.zip I'm still getting ERR

PushLocalFrame_second.txt

ajwfrost commented 2 years ago

Okay thanks .. so we maybe have different causes here.

@takazawa-gg your "NG" log has got:

2022-07-25 10:41:20.214 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 92x21 65793 10963
2022-07-25 10:41:20.215 25110-25110/? D/AdobeAIR_JNI: Creating surface/image from character bitmap 92x21 65792 11304
2022-07-25 10:41:20.215 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 92x21 65793 10963
2022-07-25 10:41:20.219 25110-25110/? I/chatty: uid=11071(u0_a1071) air.jp.globalgear.kura identical 22 lines
2022-07-25 10:41:20.219 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 92x21 65793 10963
2022-07-25 10:41:20.220 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 208x26 65793 10963
2022-07-25 10:41:20.220 25110-25110/? D/AdobeAIR_JNI: Creating surface/image from character bitmap 208x26 65792 11304
2022-07-25 10:41:20.220 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 208x26 65793 10963
2022-07-25 10:41:20.234 25110-25110/? I/chatty: uid=11071(u0_a1071) air.jp.globalgear.kura identical 98 lines
2022-07-25 10:41:20.234 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 208x26 65793 10963
2022-07-25 10:41:20.234 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 240x35 65793 10963
2022-07-25 10:41:20.234 25110-25110/? D/AdobeAIR_JNI: Creating surface/image from character bitmap 240x35 65792 11304
2022-07-25 10:41:20.235 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 240x35 65793 10963
2022-07-25 10:41:20.246 25110-25110/? I/chatty: uid=11071(u0_a1071) air.jp.globalgear.kura identical 70 lines
2022-07-25 10:41:20.246 25110-25110/? D/AdobeAIR_JNI: Creating surface/image 240x35 65793 10963
2022-07-25 10:41:20.246 25110-25110/? W/zygote64: Throwing OutOfMemoryError "PushLocalFrame"

so basically creating hundreds of cached bitmaps which are allocated via JNI. This is an area where we tried to release local references earlier so that we didn't have the issue .. however, in your "OK" trace, we don't see the additional debug lines or the changes to the push/pop local frames that we'd expect if this had worked.. so it may just be by chance that this worked, and we must have missed the appropriate mechanism being used to actually create the bitmaps...

@a9848840 yours is still failing in the text measuring and it's tricky to see why - the traces seem to have glitched slightly but to double-check we can add some changes (a) to how we're measuring the push/pop pairs, and (b) also trying to eliminate one of the calls that's made each time by caching a Java object.

New runtime is below, I would be very grateful if you're able to check with this again! Many thanks Runtime.zip

a9848840 commented 2 years ago

Hi @ajwfrost

Thank you for still following this issue use this runtime no crash

PushLocalFrame_3rd.txt

ajwfrost commented 2 years ago

Great, thanks @a9848840 - so it looks like caching the rectangle object being passed in to measuring the text has helped here; I'm not entirely sure why, since the reference should have been cleared up anyway as we left the 'getTextBounds' wrapper function... will have to double-check our 'new object' code...

@takazawa-gg if you're able to check this one too it would be good since you've got a different use case going on with bitmap caching..

thanks

a9848840 commented 2 years ago

It's great to find the problem Thank you

KupoGames commented 2 years ago

Hey, with the 3rd runtime in this thread, my app does NOT crash on startup on my Android 8 device! Here is the logcat: runtime4.txt

I tried the 2nd runtime in this thread, and it also does NOT crash: runtime3.txt

I double checked - the previous runtimes still crash.

Edit: I just noticed my project was set to "Device Release" and not "Debug", I hope the Logcats are still useful, otherwise I can do it again.

a9848840 commented 2 years ago

next version of air Can it be produced as soon as possible? thanks

ajwfrost commented 2 years ago

@KupoGames that runtime4 file looks like it's actually used a different runtime (logs says build 743...?) - the runtime3 traces show a lot of the calls to the bitmap caching via the objects we'd originally expected to be used, so it's good to see that this part is working!

@a9848840 yes I'm basically just waiting to ensure we've resolved this and will then kick off our release process...

But I'd like to get confirmation from @takazawa-gg before we're sure that we've covered all the cases...!

thanks

KupoGames commented 2 years ago

@ajwfrost sorry, I originally uploaded the wrong logcat, but I edited my comment ASAP to the correct one - maybe I didn't edit it in time.

I think this is the correct logcat for the latest runtime, it should be a 7mb file: runtime4.txt

takazawa-gg commented 2 years ago

I have a lot of meetings today and have not been able to work on it. I will check the operation right after this.

ajwfrost commented 2 years ago

@KupoGames thanks - I'd looked at the command/logs just from the email notification I got, so hadn't seen your updated comment I'm afraid! but the updated runtime log there looks good: I can see some of the surfaces are adjacent to the push/pop frame stuff which is perhaps why this is working better, but there's another location in there which I think we may want to protect in case too many of those calls were happening...

@takazawa-gg many thanks for your help :-)

takazawa-gg commented 2 years ago

@ajwfrost I have launched the app several times with the new runtime build and nothing seems to be wrong. Looking forward to the new SDK release!

ajwfrost commented 2 years ago

Great, thanks @takazawa-gg for confirming!

a9848840 commented 2 years ago

@ajwfrost

Feel sorry I want to inquire about the air progress of the next version

Hope to release soon thank you very much

ajwfrost commented 2 years ago

@a9848840 it's going through QA currently, assuming I get an 'okay' response today then we'll upload it (will see if I can get it done tonight/tomorrow morning)

a9848840 commented 2 years ago

thank you very much you help me a lot

ajwfrost commented 2 years ago

@a9848840 FYI preview is available here: https://airsdk.harman.com/download/33.1.1.926

a9848840 commented 2 years ago

@ajwfrost

i want to ask I repackage the apk today air:33.1.1.889 Not using the test runtime

crush no happen But the file itself is not modified This is confusing me how it might have happened

@KupoGames @takazawa-gg Or does anyone here have the same situation?

thank you all

ajwfrost commented 2 years ago

crash no happen But the file itself is not modified

Thanks for checking with build 889... but which file isn't modified? The fix is happening within the libCore.so file which is packaged up into the APK/AAB file via the AIR Developer Tool, and this file will have changed between each version..

thanks

a9848840 commented 2 years ago

The same file, mean my apk has not changed, the same 889, just build apk again, and then there will be no crash, so I have the above confusion

Of course, the new version is still the main

Thank you