We're investigating on an app developed by another team a native Crash on Android related to HereMaps (HERE SDK Navigation edition, navigate-4.10.2.0.7878) with this stacktrace:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.mydomain.myapp <<<
backtrace:
#00 pc 0000000000051010 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
#00 pc 0000000000e0143c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e0158c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e014f4 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e01478 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000debfe4 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000144cc84 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000014035bc /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000013fa668 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000155cff0 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000011273f8 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so (Java_com_here_sdk_navigation_VisualNavigator_disposeNativeHandle+480)
#00 pc 0000000000042020 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (art_jni_trampoline+96)
#00 pc 000000000020988c /apex/com.android.art/lib64/libart.so (nterp_helper+1948)
#00 pc 0000000000b6999c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator.access$000)
#00 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52)
#00 pc 0000000000b69974 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator$1.disposeNative)
#00 pc 0000000000073c6c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (com.here.NativeBase$DisposableReference.dispose+156)
#00 pc 000000000020a0a0 /apex/com.android.art/lib64/libart.so (nterp_helper+4016)
#00 pc 00000000009a3834 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.cleanUpQueue+26)
#00 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52)
#00 pc 00000000009a380e /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.access$100)
#00 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52)
#00 pc 00000000009a37be /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>+22)
#00 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
#00 pc 00000000009a37ca /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>)
#00 pc 000000000020a748 /apex/com.android.art/lib64/libart.so (nterp_helper+5720)
#00 pc 00000000009a37fc /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.<init>+28)
#00 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
#00 pc 00000000009ac7f8 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.core.threading.RunnableImpl.<init>+10)
#00 pc 00000000002cdd64 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548)
#00 pc 00000000003d5660 /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallNonvirtualVoidMethodV(_JNIEnv*, _jobject*, _jclass*, _jmethodID*, std::__va_list)+492)
#00 pc 00000000003d4ab4 /apex/com.android.art/lib64/libart.so (art::JNI<false>::NewObjectV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+736)
#00 pc 0000000000e0e858 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e37fac /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e37a5c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000140dad0 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000144c5e8 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000144d2bc /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000000b2fd0 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264)
#00 pc 0000000000052834 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
EDIT:
After some refactoring and cleaning operations in our code we've reached a clean condition in which we are confident that there aren't any leak; we've used LeakCanary to investigate and remove all these ones, but the native crash it's still here.
So we've tried to return back to basis and we've cloned HEREMaps Navigate Samples from github and we've found that in Navigation Sample there isn't any native crash, but there is also an only activity with heremaps instance references which die within the entire application.
To replicate a similar use case then our we've added an activity before the MainActivity of the Sample and we've tried to launch the activity and return back to the first one to show what is the behaviour of the library in terms of resources releasing.
Only opening and closing MainActivity from a starting one doesn't have any native crash also because VisualNavigator (which seems to be the class with native crash in the backtrace) is retained by it's delegates (aka Listeners) => setupListeners() in NavigationExample. So we've also removed all listeners when MainActivity calls onDestroy and in this way we see always the same native crash as in our app, going back from MainActivity to starting one.
Note: to be able to always reproduce the native crash we use LeakCanary because the library force GC when MainActivity has been destroyed; if we remove it the GC operation is done randomly by the system.
Links:
our version of HEREMaps Navigation SDK sample modified to reproduce native crash on github
video of crash of the sample: https://youtube.com/shorts/edY-TRvWh3I
So the big question here is: have we implemented wrong HEREMaps SDK integration (and managing instance releasing) or this native crash is inside the library and has to be fixed from the library owner?
Try find a way to make the VisualNavigator persistent:
Using StopRendering() is fine but do not null the VisualNavigator.
I had to go through the same issue when cancelling the route too quickly, although it got way worse over the recent updates and just crashes when just stopping navigation and this fixes it.
In the HERE SDK developer's guide there is a chapter that shows how to stop navigation. It is recommended to call stopRendering(). In your example app, it seems you do not call visualNavigator.stopRendering() when the intermediate activity gets destroyed. Try to call it.
In the developer options menu of the device you can turn on "Don't keep activities" to simulate such scenarios.
Related
Lately, we're experiencing native crashes spike in production. All those crashes are related to rendering UI and happened mostly on Android 12 and vendors like Samsung. Some of them from Play Console are:
[libhwui.so] SkCanvas::restore()
SIGSEGV
backtrace:
#00 pc 0x000000000026c9d8 /system/lib64/libhwui.so (SkCanvas::restore()+344)
#01 pc 0x000000000026c73c /system/lib64/libhwui.so
(android::SkiaCanvas::restore()+52)
#02 pc 0x00000000002008e0 /system/lib64/libhwui.so
(android::CanvasJNI::restore(long)+56)
#03 pc 0x0000000000bef14c /data/misc/apexdata/com.android.art/dalvik-
cache/arm64/boot.oat (android.graphics.Canvas.restore+60)
or
[[vdso]] __kernel_rt_sigreturn
SIGSEGV
#00 pc 0x00000000001ac258 /apex/com.android.art/lib64/libart.so
(art::ArtMethod::GetOatQuickMethodHeader(unsigned long)+40)
#01 pc 0x0000000000597864 /apex/com.android.art/lib64/libart.so (void
art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+516)
#02 pc 0x000000000059a514 /apex/com.android.art/lib64/libart.so
(art::StackVisitor::GetVRegFromDebuggerShadowFrame(unsigned short, art::VRegKind,
unsigned int*) const+284)
#03 pc 0x000000000059a314 /apex/com.android.art/lib64/libart.so
(art::StackVisitor::GetVReg(art::ArtMethod*, unsigned short, art::VRegKind, unsigned
int*, std::__1::optional<art::DexRegisterLocation>) const+76)
But we cannot understand their cause because neither Firebase Crashlytics nor other third parties can catch native crashes. We've googled everything and found nothing about how to get more data for the native crashes to find the cause. Maybe somebody has an experience with it and can share.
I see crash report with native stack like this in the Google Play Console:
**#00 pc 0x0000000000142eb0 /vendor/lib/egl/libGLESv2_mtk.so
#00 pc 0x000000000008560f /vendor/lib/egl/libGLESv2_enter code heremtk.so
#00 pc 0x000000000004e87b /vendor/lib/egl/libGLESv2_mtk.so
#00 pc 0x00000000000861c5 /vendor/lib/egl/libGLESv2_mtk.so
#00 pc 0x000000000008655f /vendor/lib/egl/libGLESv2_mtk.so (glClear)
#00 pc 0x000000000002c2ed /vendor/lib/egl/libGLES_meow.so (MEOW::meow_call_ddk_gl_2_glClear(unsigned int))
#00 pc 0x0000000002d59a6f /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002d2d1c5 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002d2dc9f /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002d2da2f /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002d2d8c9 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002d2d83d /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002c99b47 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000223b189 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000223b9b9 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000184f827 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000223da77 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000223ae9b /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000223abef /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x000000000223aadf /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x0000000002195ef9 /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x00000000022309fd /data/app/~~d83lw_YrzoAtUPAKGWYbjw==/com.google.android.trichromelibrary_511209730-GjEIgDuST31-hubNOyffqA==/base.apk!libmonochrome.so
#00 pc 0x00000000000807b3 /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*))
#00 pc 0x0000000000039d83 /apex/com.android.runtime/lib/bionic/libc.so (__start_thread)**
So far, I haven't been able to reproduce this bug / problem / crash
And I found that this crashenter code here only occurs in the Philippines country, and the android system is 9.0 and above.
country img
cpu img
system img
My Android app is suffering from an'abort' error after recent update.
But I don't know why this problem happens and how can I debug it.
This 'abort' error occurred especially on Android 10 and 11.
It is not recorded on Firebase Crashlytics, I can see it only on Google play console.
The log is as below.
backtrace:
#00 pc 000000000004ef24 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
#00 pc 000000000053b078 /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+2340)
#00 pc 000000000001394c /system/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+76)
#00 pc 00000000000130cc /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+312)
#00 pc 000000000058e1d4 /apex/com.android.art/lib64/libart.so (art::Thread::AssertNoPendingException() const+1836)
#00 pc 00000000001c15cc /apex/com.android.art/lib64/libart.so (art::ClassLinker::FindClass(art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+64)
#00 pc 0000000000380c34 /apex/com.android.art/lib64/libart.so (art::JNI<false>::FindClass(_JNIEnv*, char const*)+1144)
#00 pc 00000000000200d4 /data/app/~~0HXm4UzxwERXczUAACEC9g==/com.****.****-L0QwKgab-Tg3REmBFsu7iA==/lib/arm64/libmm.so
#00 pc 0000000000020b90 /data/app/~~0HXm4UzxwERXczUAACEC9g==/com.****.****-L0QwKgab-Tg3REmBFsu7iA==/lib/arm64/libmm.so
#00 pc 00000000000b6234 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64)
#00 pc 0000000000050e64 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
I applied 'View Binding' to this update.
Could it be an cause?
Also I wonder if an Android app can be alive when 'abort' error occurred.
Please help me...
libmm is a file of an obfuscation solution which we applied to the app. It is a binary obfuscation solution and it is run before application runs on memory as far as I know.
since December 2015, we are experiencing a strange crash only on a limited number of devices running Android 6.0 and 6.0.1. Most of them are Nexus 5.
First the log of the crash pulled from the Play Store. Looking int art_method.cc, it looks like the mapping of a certain method to native code fails. Maybe it is compilation induced?
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/hammerhead/hammerhead:6.0.1/MMB29Q/2480792:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 18737, tid: 18737, name: omittedapp >>> com.omitteddomain.omittedapp <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/art_method.cc:245] Failed to find native offset for dex pc 0x58 in android.view.View com.omitteddomain.omittedapp.PlotWidget.a(android.view.ViewGroup, android.view.LayoutInflater, java.util.List)'
r0 00000000 r1 00004931 r2 00000006 r3 b6f24b7c
r4 b6f24b84 r5 b6f24b34 r6 00000001 r7 0000010c
r8 b4c3f800 r9 b4c3de44 sl b361d3db fp b4c23450
ip 00000006 sp beb2ca90 lr b6c93b61 pc b6c95f50 cpsr 40070010
backtrace:
#00 pc 00041f50 /system/lib/libc.so (tgkill+12)
#01 pc 0003fb5d /system/lib/libc.so (pthread_kill+32)
#02 pc 0001c30f /system/lib/libc.so (raise+10)
#03 pc 000194c1 /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000174ac /system/lib/libc.so (abort+4)
#05 pc 00333971 /system/lib/libart.so (art::Runtime::Abort()+228)
#06 pc 000f45fb /system/lib/libart.so (art::LogMessage::~LogMessage()+2226)
#07 pc 000f08d1 /system/lib/libart.so (art::Barrier::~Barrier()+216)
#08 pc 0035b473 /system/lib/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+162)
#09 pc 00333a35 /system/lib/libart.so (art::Runtime::Abort()+424)
#10 pc 000f45fb /system/lib/libart.so (art::LogMessage::~LogMessage()+2226)
#11 pc 000ef88b /system/lib/libart.so (art::ArtMethod::ToNativeQuickPc(unsigned int, bool)+918)
#12 pc 00329055 /system/lib/libart.so (art::CatchBlockStackVisitor::VisitFrame()+180)
#13 pc 0033ccbd /system/lib/libart.so (art::StackVisitor::WalkStack(bool)+224)
#14 pc 0032910d /system/lib/libart.so (art::QuickExceptionHandler::FindCatch(art::mirror::Throwable*)+92)
#15 pc 0034a61d /system/lib/libart.so (art::Thread::QuickDeliverException()+140)
#16 pc 003fb7d9 /system/lib/libart.so (artThrowNullPointerExceptionFromCode+20)
#17 pc 00a15f01 /data/app/com.omitteddomain.omittedapp-1/oat/arm/base.odex (offset 0x59d000)
The only other occurrence of a similar crash (here Android ART: "Failed to find Dex offset for PC offset ...") has been reported to be potentially related to an infinite recursion issue. While we had an infinite recursion issue in the very same "a" method, it has been already fixed.
Some additional info:
The PlotWidget class in question display a chart to the user via a third party library. The cart view is configured inside the above "a" method. We changed the library multiple times with no difference in the outcome.
All of the third party libraries are up to date.
We have been able to test the app with the same data displayed to one of the afflicted user, without being able to reproduce the issue (being sensitive information, we were provided only the data strictly required to render the chart).
Attempts to reproduce the issue have failed with every combination of configuration/flavor, proguard enabled/disabled, zipalign yes/no, etc.
The app is compiled with Android Studio 1.5, with the latest SDK, targeting API 23. Before setting a lower target API and release an useless update for the umpteenth time, I'd like to know is someone experienced and solved similar issues.
Any advice is welcome.
my android crashes sometimes for some of the users which i am able to see google developer console.
Below is the crash log for the entire crash which i extracted out of google break pad. The crash clearly says that in the following function
js_cocos2dx_TextFieldTTF_textFieldWithPlaceHolder
but i am not able to uderstand as to why this is happening. I am currently using cocos2dx-js v 3.5.
Any help or idea as to why this crash happens would be highly useful.
Build fingerprint: 'motorola/falcon_bwaca/falcon_umts:4.4.4/KXB21.14-L1.50-1/1:user/release-keys'
pid: 30910, tid: 31705, name: Thread-6337 >>> in..test <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Stack frame #00 pc 00022160 /system/lib/libc.so (tgkill+12)
Stack frame #01 pc 000131b1 /system/lib/libc.so (pthread_kill+48)
Stack frame #02 pc 000133c5 /system/lib/libc.so (raise+10)
Stack frame #03 pc 000120fb /system/lib/libc.so
Stack frame #04 pc 00021a14 /system/lib/libc.so (abort+4)
Stack frame #05 pc 00c41251 libcocos2djs.so (__gnu_cxx::__verbose_terminate_handler()+228): Routine js_cocos2dx_TextFieldTTF_textFieldWithPlaceHolder(JSContext*, unsigned int, JS::Value*) at jsb_cocos2dx_auto.cpp:60716