Shulou(Shulou.com)06/02 Report--

Java code caused by NATIVE wild pointer problem how to solve, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Implement hook:

We have hook, but we don't yet know which so released functor.

If you're not sure which so it is, you can just hook a few more so.

Of course, for specific examples, there are techniques to determine so, such as our example:

The object being destructed is an object of the Functor class, and we can get it from log because of its vtbl address.

The vtbl generally points to the so that defines the class, so you can use the 0×73648de0 to look in the map table to determine which so it is.

73635000-73646000 rw-p 00000000 00:00 0 73646000-73648000 r-xp 00000000 b3Vl18 1287 / system/lib/libwebviewchromium_plat_support.so = > 73648000-73649000rMurray p 00001000b3VO18 1287 / system/lib/libwebviewchromium_plat_support.so 73649000-7364a000 rw-p 00002000b3VO18 1287 / system/lib/libwebviewchromium_plat_support.so 7364a000-73684000 rw-p 00000000000 00:00 073684000-73696000 r-xp 00000000 b3RV 18 1034 / system/lib/libjavacrypto.so 73696000-73697000 Rafael Musi p 00011000 b3 system/lib/libjavacrypto.so 18 1034 / system/lib/libjavacrypto.so 73697000-73698000 rw-p 00012000 b3 Swiss 18 1034 / system/lib/libjavacrypto.so.

It should be noted that the release of C++ objects is the delete function.

Instead of calling the free function of libc directly, libwebviewchromium_plat_support.so calls the delete function in libc++.so, and then the delete function calls the free function.

So we have the free function of hook libc++.so, but the module that prints the call stack also depends on libc++.so, so if we print the call stack in the hook function, we will also encounter the problem of endless loop.

So we have the delete function in hook libwebviewchromium_plat_support.so, which not only reduces the amount of log, but also avoids the endless loop.

First confirm whether libwebviewchromium_plat_support.so relies on the delete function:

$readelf-s libwebviewchromium_plat_support.so | grep UND 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 FUNC GLOBAL DEFAULT UND _ _ cxa_finalize 2: 00000000 0 FUNC GLOBAL DEFAULT UND _ _ cxa_atexit 4: 00000000 0 FUNC GLOBAL DEFAULT UND _ aeabi_unwind_cpp_pr0 5: 00000000 0 FUNC GLOBAL DEFAULT UND _ aeabi_unwind_cpp_pr1 6: 00000000 0 FUNC GLOBAL DEFAULT UND getrlimit 7: 00000000 0 FUNC GLOBAL DEFAULT UND setrlimit 8: 00000000 0 FUNC GLOBAL DEFAULT UND _ errno 9: 00000000 0 FUNC GLOBAL DEFAULT UND strerror 10: 00000000 0 FUNC GLOBAL DEFAULT UND _ android_log_print = > 11: 00000000 0 FUNC GLOBAL DEFAULT UND _ Znwj = > 12: 00000000 0 FUNC GLOBAL DEFAULT UND _ ZdlPv 14: 00000000 0 FUNC GLOBAL DEFAULT UND _ android_log_assert... 51: 00000000 0 FUNC GLOBAL DEFAULT UND _ _ aeabi_llsr 52: 00000000 0 OBJECT GLOBAL DEFAULT UND _ _ popcount_tab

Where 11 items _ Znwj are symbols for new and _ ZdlPv are symbols for delete.

Next, use the delete function of the tool hook libwebviewchromium_plat_support.so:

Extern void _ ZdlPv (void*); void inject__ZdlPv (void* ptr) {LOGD ("delete% p", ptr); dumpNativeStack (); dumpJavaStack (); _ ZdlPv (ptr);}

The problem reappears after hook, and the log caught is as follows:

10-27 21 clz=com.miui.player.display.view.DisplayFragmentLayout 19V 52.961 8027 8027 D ObserverLayout: onStop: clz=com.miui.player.display.view.DisplayFragmentLayout {45665838 V.E. 0 MusicBaseFragment 0-1080 MusicBaseFragment 1920 # 7f080039 app:id/content} 10-27 21 Fraser 1915 Vol 52.965 8027 8027 I: onDestroyView the view is still attached Delay destroy 10-27 21 INJECT 19V 52.966 8027 8027 D INJECT: delete 0x7a7b8530 10-27 21 V 19V 52.986 8027 8027 D INJECT: # 00 pc 000015f6 / system/lib/libinject.so (inject__ZdlPv+21) 10-27 21 V 19V 52.986 8027 8027 D INJECT: # 01 pc 00001134 / system/lib/libwebviewchromium_plat_supp 10-27 21 V 19V 52.986 8027 8027 D INJECT: # 02 pc 00001088 / system/lib/libwebviewchromium_plat_supp 10-27 21 system/lib/libdvm.so 19V 52.987 8027 8027 D INJECT: # 03 pc 0001d30c / system/lib/libdvm.so (dvmPlatformInvoke+112) 10-27 21 V 19V 52.987 8027 8027 D INJECT: # 04 pc 0004d8da / system/lib/libdvm.so (dvmCallJNIMethod (unsigned int const*) JV+397) 10-27 21 system/lib/libdvm.so 19V 52.987 8027 8027 D INJECT: # 05 pc 00026720 / system/lib/libdvm.so 10-27 21 V 19V 52.987 8027 8027 D INJECT: # 06 pc 0002d790 / system/lib/libdvm.so (dvmMterpStd (Thread*) + 76) 10-27 21 V 19V 52.987 8027 8027 D INJECT: # 07 pc 0002adf4 / system/lib/libdvm.so (dvmInterpret (Thread*, Method const*) JVa+184) 10-27 21 pc 19V 52.988 8027 8027 D INJECT: # 08 pc 00060058 / system/lib/libdvm.so (dvmInvokeMethod (Object*, Method const* + 10-27 21 system/lib/libdvm.so 19V 52.988 8027 8027 D INJECT: # 09 pc 00067ff6 / system/lib/libdvm.so 10-27 21 V 19V 52.988 8027 8027 D INJECT: # 10 pc 00026720 / system/lib/libdvm.so 10-27 21 V 19V 52.988 8027 8027 D INJECT: # 11 pc 0002d790 / system/lib/libdvm.so (dvmMterpStd (Thread*) + 76) 10-27 2119 purge 52.988 8027 8027 D INJECT: # 12 pc 0002adf4 / system/lib/libdvm.so (dvmInterpret (Thread*) Method const*, JVa+184) 10-27 21 pc 0005fd74 19V 52.988 8027 8027 D INJECT: # 13 pc 0005fd74 / system/lib/libdvm.so (dvmCallMethodV (Thread*, Method const* INJECT: # 14 pc 000494c2 / system/lib/libdvm.so 10-27 21 INJECT 19V 52.989 8027 8027 D INJECT: at com.android.webview.chromium.DrawGLFunctor.nativeDestroyGLFunctor (Native Method) 10-27 21 V 19V 52.989 8027 8027 D INJECT: at com.android.webview.chromium.DrawGLFunctor.access$000 (DrawGLFunctor.java:31) 10-27 21 V 19V 1952.989 8027 8027 D INJECT: at com .android.webview.chromium.DrawGLFunctor $DestroyRunnable.run (DrawGLFunctor.java:91) 10-27 21 INJECT 19V 52.989 8027 8027 D INJECT: at com.android.org.chromium.content.common.CleanupReference.runCleanupTaskInternal (CleanupReference.java:159) 10-27 21 V 19V 52.989 8027 8027 D INJECT: at com.android.org.chromium.content.common.CleanupReference.access$300 (CleanupReference.java:32) 10-27 21 at com.android.org.chromium.content.common.CleanupReference.runCleanupTaskInternal 19V 52.989 8027 8027 D INJECT: at com.android.org .chromium.content.common.CleanupReference $LazyHolder$1.handleMessage (CleanupReference.java:93) 10-27 21 at com.android.org.chromium.content.common.CleanupReference.handleOnUiThread 19V 52.990 8027 8027 D INJECT: at com.android.org.chromium.content.common.CleanupReference.handleOnUiThread (CleanupReference.java:147) 10-27 21 V 19V 52.990 8027 8027 D INJECT: at com.android.org.chromium.content.common.CleanupReference.cleanupNow (CleanupReference.java:141) 10-27 at com.android.org.chromium.content.common.CleanupReference.handleOnUiThread 2119 at com.android.org.chromium.content.common.CleanupReference.handleOnUiThread 52.990 8027 8027 D INJECT: at com.android.webview .chromium.DrawGLFunctor.function. Chromium.DrawGLFunctor.function (DrawGLFunctor.java:46) 10-27 21 at com.android.webview.chromium.WebViewChromium.destroy 19V 52.990 8027 8027 D INJECT: at com.android.webview.chromium.WebViewChromium.destroy (WebViewChromium.java:430) 10-27 21 V 19V 52.990 8027 8027 D INJECT: at android.webkit.WebView.destroy (WebView.java:667) 10-27 21 WebViewChromium.java:430 19V 52.990 8027 8027 D INJECT: at com.xiaomi.music.hybrid.HybridFragment.destroyHybridView (HybridFragment.java:64) 10-27 INJECT: at com.miui.player.component.MusicBaseFragment.onDestroyView (MusicBaseFragment.java:216) 10-27 21 HybridFragment.java:115 19INJECT 52.991 8027 8027 D INJECT: at android.app.Fragment.performDestroyView (Fragment.java:1898) 10-27 21 INJECT 19V 52.991 8027 8027 D INJECT: at android .app.FragmentManagerImpl.moveToState (FragmentManager.java:954) 10-27 21V 19V 52.991 8027 8027 D INJECT: at android.app.FragmentManagerImpl.removeFragment (FragmentManager.java:1167) 10-27 21V 19V 52.991 8027 8027 D INJECT: at android.app.BackStackRecord.popFromBackStack (BackStackRecord.java:715) 10-27 21V 19V 52.991 8027 D INJECT: at android.app.FragmentManagerImpl.popBackStackState (FragmentManager.java:1544) 10-27 21V 19V 52.992 8027 8027 D INJECT: at android.app.FragmentManagerImpl$3.run (FragmentManager.java:502) 10-27 21 INJECT 19V 52.992 8027 8027 D INJECT: at android.app.FragmentManagerImpl.execPendingActions (FragmentManager.java:1449) 10-27 21 V 19V 52.992 8027 8027 D INJECT: at android.app.FragmentManagerImpl$1.run (FragmentManager.java:443) 10-27 21 V 19V 52.992 8027 8027 D INJECT: at android.os.Handler.handleCallback (Handler.java:733) 10-27 21 Handler.java:95 19INJECT 52.992 8027 8027 D INJECT: at android.os.Handler.dispatchMessage (Handler.java:95) 10-27 21V 19V 52.992 8027 8027 D INJECT: at android.os.Looper.loop (Looper.java:136) 10-27 21V 19V 52.993 8027 8027 D INJECT: at android.app.ActivityThread.main (ActivityThread.java:5016) 10-27 21V 19V 52.993 8027 8027 D INJECT: at java.lang.reflect.Method.invokeNative (Native Method) 10-27 21 at java.lang.reflect.Method.invoke 8027 8027 D INJECT: at java.lang.reflect.Method.invoke (Method.java:515) 10-27 21 Method.java:515 19V 52.993 8027 8027 D INJECT: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:792) 10-27 21 V 19V 52.993 8027 8027 D INJECT: at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:608) 10-27 21 Method.java:515 19V 52.993 8027 8027 D INJECT: at dalvik.system.NativeStart.main (Native Method) 10-27 21 Native Method 19 OpenGLRenderer 53.020 8027 8027 I OpenGLRenderer: functor=0x7a7b8530 Vtbl=0x400fc1b8

As you can see from log, it is true that Functor was released during distroy view, and then the Functor was used in Renderer.

The java call stack when the print crashes is as follows:

10-27 21 dalvikvm 19prio=5 tid=1 TIMED_WAIT10 53.274 8027 8027 I dalvikvm: "main" main-27 21 dalvikvm 19V 53.279 8027 8027 I dalvikvm: | group= "main" sCount=0 dsCount=0 obj=0x41716ca8 self=0x415344f8 10-27 21 dalvikvm 19V 53.279 8027 8027 I dalvikvm: | sysTid=6895 nice=-6 sched=0/0 cgrp=apps handle=1074409812 10-27 21 utm=184 stm=61 core=3 1915 53.280 8027 8027 I dalvikvm: | state=R schedstat= (000) utm=184 stm=61 core=3 10-27 21 dalvikvm 1915 53.280 8027 8027 I dalvikvm: at android. View.GLES20Canvas.nDrawDisplayList (Native Method) 10-27 21 dalvikvm 19V 53.281 8027 8027 I dalvikvm: at android.view.GLES20Canvas.drawDisplayList (GLES20Canvas.java:420) 10-27 21 V 19V 53.281 8027 8027 I dalvikvm: at android.view.HardwareRenderer$GlRenderer.drawDisplayList (HardwareRenderer.java:1709) 10-27 21 V 19V 53.281 8027 8027 I dalvikvm: at android.view.HardwareRenderer$GlRenderer.draw (HardwareRenderer.java:1525) 10-27 21 V 19V 53.282 8027 8027 I dalvikvm: at android .view.ViewRootImpl.draw (ViewRootImpl.java:2475) 10-27 21 at android.view.ViewRootImpl.performDraw 19V 53.282 8027 8027 I dalvikvm: at android.view.ViewRootImpl.performDraw (ViewRootImpl.java:2347) 10-27 21 at android.view.ViewRootImpl.performDraw 19V 53.283 8027 8027 I dalvikvm: at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:1977) 10-27 21 ViewRootImpl.java:2347 19V 53.284 8027 8027 I dalvikvm: at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1094) 10-27 21R 19V 53.285 8027 8027 I At android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:5703) 10-27 21 dalvikvm 19V 53.285 8027 8027 I dalvikvm: at android.view.Choreographer$CallbackRecord.run (Choreographer.java:764) 10-27 21 V 19V 53.286 8027 8027 I dalvikvm: at android.view.Choreographer.doCallbacks (Choreographer.java:577) 10-27 21 V 19V 53.287 8027 8027 I dalvikvm: at android.view.Choreographer.doFrame (Choreographer.java:547) 10-27 21 V 19V 53.288 8027 8027 I dalvikvm: at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:750) 10-27 21 Choreographer.java:750 19 dalvikvm 53.289 8027 8027 I dalvikvm: at android.os.Handler.handleCallback (Handler.java:733) 10-27 21 V 19V 53.289 8027 8027 I dalvikvm: at android.os.Handler.dispatchMessage (Handler.java:95) 10-27 21 V 19V 53.290 8027 8027 I dalvikvm: at android.os.Looper.loop (Looper.java:136) 10-27 21:19 : 53.291 8027 8027 I dalvikvm: at android.app.ActivityThread.main (ActivityThread.java:5016) 10-27 21 ActivityThread.java:5016 19 dalvikvm 53.291 8027 8027 I dalvikvm: at java.lang.reflect.Method.invokeNative (Native Method) 10-27 21 dalvikvm 19 dalvikvm 53.292 8027 8027 I dalvikvm: at java.lang.reflect.Method.invoke (Method.java:515) 10-27 21 21 19 dalvikvm 53.293 8027 8027 I dalvikvm: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run 8027 I dalvikvm: at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:608) 10-27 21 ZygoteInit.java:608 19 dalvikvm: at dalvik.system.NativeStart.main (Native Method)

Normally, view should not be drawn after being destroy. By communicating with Sun Nian, we learned that this situation may be caused by view's lack of remove before destroy.

Analyze the code:

There are two special lines in the call stack for delete above:

10-27 21 INJECT 19 INJECT 52.990 8027 8027 D INJECT: at com.xiaomi.music.hybrid.HybridFragment.destroyHybridView (HybridFragment.java:64) 10-27 21 21 INJECT: at com.xiaomi.music.hybrid.HybridFragment.onDestroyView (HybridFragment.java:115)

This is the code of the application, and this problem has only occurred in this application, so it is probably caused by the code of the application.

So look at the code in opengrok and find that there are two implementations of destroyHybridView ():

@ v8-kk-pisces-alpha/packages/apps/MiuiMusic/common/music_sdk/hybrid/src/com/xiaomi/music/hybrid/HybridFragment.java private void destroyHybridView () {for (HybridView view: mHybridViews) {if (view! = null) {view.destroy ();}} mHybridViews.clear () } @ v8-kk-pisces-alpha/packages/apps/MiuiSdk/library/src/java/miui/hybrid/HybridFragment.java private void destroyHybridView () {for (HybridView view: mHybridViews) {if (view! = null) {= > if (view.getParent ()! = null) {= > ((ViewGroup) view.getParent ()) .removeView (view) = >} view.destroy ();}} mHybridViews.clear ();}

After communicating with my colleagues in the app, I learned that the music app uses the above code, that is, there is no removeView code.

Add the logic of removeView to the above code and do not reproduce the problem.

Although the problem has been resolved, it is not clear why there is no removeView causing wild pointers.

In order to find the root cause, I carefully read the relevant code, and found that there is detachFunctor code in the Render code:

Class GLES20Canvas extends HardwareCanvas {... Public void detachFunctor (int functor) {nDetachFunctor (mRenderer, functor);}

Set a breakpoint in this code with studio to get the call stack as follows:

Java.lang.Thread.State: RUNNABLE at android.view.GLES20Canvas.detachFunctor (GLES20Canvas.java:321) at android.view.HardwareRenderer$GlRenderer.detachFunctor (HardwareRenderer.java:1791) at android.view.ViewRootImpl.detachFunctor (ViewRootImpl.java:744) at com.android.webview.chromium.DrawGLFunctor$DestroyRunnable.detachNativeFunctor (DrawGLFunctor.java:97) at com.android.webview.chromium.DrawGLFunctor.detach (DrawGLFunctor.java:53) at com.android.webview.chromium.WebViewChromium .onDetachedFromWindow (WebViewChromium.java:1718) at android.webkit.WebView.onDetachedFromWindow (WebView.java:2108) at android.view.View.dispatchDetachedFromWindow (View.java:12631) at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:2587) at android.view.ViewGroup.removeViewInternal (ViewGroup.java:3845) at android.view.ViewGroup.removeViewInternal (ViewGroup.java:3818) at android.view.ViewGroup.removeView (ViewGroup.java:3750) At com.xiaomi.music.hybrid.HybridFragment.destroyHybridView (HybridFragment.java:66) at com.xiaomi.music.hybrid.HybridFragment.onDestroyView (HybridFragment.java:119) at com.miui.player.component.MusicBaseFragment.onDestroyView (MusicBaseFragment.java:216) at android.app.Fragment.performDestroyView (Fragment.java:1898) at android.app.FragmentManagerImpl.moveToState (FragmentManager.java:954) at android.app.FragmentManagerImpl.removeFragment (FragmentManager.java:1167) At android.app.BackStackRecord.popFromBackStack (BackStackRecord.java:715) at android.app.FragmentManagerImpl.popBackStackState (FragmentManager.java:1544) at android.app.FragmentManagerImpl$3.run (FragmentManager.java:502) at android.app.FragmentManagerImpl.execPendingActions (FragmentManager.java:1449) at android.app.FragmentManagerImpl$1.run (FragmentManager.java:443) at android.os.Handler.handleCallback (Handler.java:733) at android.os.Handler.dispatchMessage (Handler.java 95) at android.os.Looper.loop (Looper.java:136) at android.app.ActivityThread.main (ActivityThread.java:5016) at java.lang.reflect.Method.invokeNative (Method.java:-1) at java.lang.reflect.Method.invoke (Method.java:515) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:792) at com.android.internal.os.ZygoteInit.main (ZygoteInit. Java:608) at dalvik.system.NativeStart.main (NativeStart.java:-1)

When removeView is added, the Functor is removed from the Render so that Render no longer calls the Functor when drawing.

This problem will only exist on KK, L will make great changes to Render later, even if you do not do removeView, there will be no wild pointer problem.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.