的WebView查杀整个活动---如何调试呢？ [英] WebView killing the whole activity --- How can I debug this?
问题描述
我有一个奇怪的问题，我不知道该怎么面对。
I have a strange problem that I don't know how to face.
我的应用程序使用的WebView加载HTML应用程序。这是一个漫长而复杂的应用程序，这也涉及JavaScriptInterfaces。
My application uses a WebView to load a HTML app. It is a long and complex app, that also involves JavaScriptInterfaces.
最近，我收到本地的WebCore模块，全杀活动核心转储。
Lately I am getting Core Dumps in the native webcore module that kill the whole activity.
它有时会发生，但常常，我们说每5次1。
It happens sometimes, but frequently, let's say 1 of every 5 times.
它总是同时的WebView加载应用程序发生，但在不同的地方。它看起来像一个导出的Java函数调用涉及，但不是特定的一个。我重构亿万倍一切，虽然有时它似乎解决了，它只是一个运气的问题。突然，再次失败。
It always happens while WebView is loading the app, but on different places. It looks like a call to an exported Java function is involved, but not a specific one. I've refactored a zillion times everything and, while sometimes it seems resolved, it's just a matter of luck. Suddenly it fails again.
如果WebView中完成加载和INITING应用程序，它永远不会崩溃。它装载/初始化/启动执行过程中才会发生。
If WebView finishes loading and initing the app, it NEVER crashes. It only happens during load/init/start execution.
这几乎总是出现是唯一的模式，它看起来像它总是在同一个地方崩溃了：
The only pattern that nearly always appears is, it looks like it always crashes in the same place:
I/DEBUG (30186): #00 pc 003a37a4 /system/lib/libwebcore.so (_ZNK5Layer8getChildEi)
I/DEBUG (30186): #01 pc 00285bae /system/lib/libwebcore.so
I/DEBUG (30186): #02 pc 0001edb0 /system/lib/libdvm.so (dvmPlatformInvoke)
I/DEBUG (30186): #03 pc 000594ba /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
当然，我知道这是一个不完整的问题，我会后要求什么，但我想回答，如果有人对我怎么能猜出或多或少怎么回事，我的意思是一个想法，可以我期待与地方该堆栈跟踪？当涉及到Android原生层，我完全丧失。
Of course, I know this is an incomplete question, I'll post anything on request, but I'd like to answer if somebody has an idea on how can I guess what's more or less going on, I mean, can I look somewhere with this stack trace?? I am completely lost when it comes to the Android Native Layer.
如果只有我知道任何关系崩溃，我可以重构的Java或JavaScript，但我完全失明，并不亚于我提出的一切似乎没有任何改善....
If only I knew any relation to the crash I could refactor Java or JavaScript, but I'm completely blind, and as much as I have moved everything nothing seems to improve....
在此先感谢！
PD-我在ICS v.4.04了三星Galaxy Tab 10.1
PD- I am on ICS v.4.04 with a Samsung Galaxy Tab 10.1
/libc ( 575): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
I/DEBUG (30186): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG (30186): Build fingerprint: 'samsung/GT-P7500/GT-P7500:4.0.4/IMM76D/XXLQ8:user/release-keys'
I/DEBUG (30186): pid: 575, tid: 591 >>> com.regaliz.libneo <<<
I/DEBUG (30186): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG (30186): r0 0117f608 r1 00000000 r2 00feb880 r3 00000000
I/DEBUG (30186): r4 00feb880 r5 00ffb568 r6 00000007 r7 50fbfe0c
I/DEBUG (30186): r8 5bf04c10 r9 50fbfe04 10 00000000 fp 5bf04c24
I/DEBUG (30186): ip 5a229ba5 sp 5bf04c08 lr 5a229bb3 pc 5a3477a4 cpsr 800f3430
I/DEBUG (30186): d0 0000000042c80000 d1 0000000043ae0000
I/DEBUG (30186): d2 3f00000043ae0000 d3 43ae000041c80000
I/DEBUG (30186): d4 00000000432e0000 d5 411efaf800000000
I/DEBUG (30186): d6 3fe03e1c9b413986 d7 41d4634c06a07c39
I/DEBUG (30186): d8 0000000000000000 d9 0000000000000000
I/DEBUG (30186): d10 0000000000000000 d11 0000000000000000
I/DEBUG (30186): d12 0000000000000000 d13 0000000000000000
I/DEBUG (30186): d14 0000000000000000 d15 0000000000000000
I/DEBUG (30186): scr 20000011
I/DEBUG (30186):
I/DEBUG (30186): #00 pc 003a37a4 /system/lib/libwebcore.so (_ZNK5Layer8getChildEi)
I/DEBUG (30186): #01 pc 00285bae /system/lib/libwebcore.so
I/DEBUG (30186): #02 pc 0001edb0 /system/lib/libdvm.so (dvmPlatformInvoke)
I/DEBUG (30186): #03 pc 000594ba /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
I/DEBUG (30186): #04 pc 00030c0c /system/lib/libdvm.so
I/DEBUG (30186): #05 pc 000343e4 /system/lib/libdvm.so (_Z12dvmInterpretP6ThreadPK6MethodP6JValue)
I/DEBUG (30186): #06 pc 0006ce76 /system/lib/libdvm.so (_Z14dvmCallMethodVP6ThreadPK6MethodP6ObjectbP6JValueSt9__va_list)
I/DEBUG (30186): #07 pc 0006ce98 /system/lib/libdvm.so (_Z13dvmCallMethodP6ThreadPK6MethodP6ObjectP6JValuez)
I/DEBUG (30186): #08 pc 0005ffe0 /system/lib/libdvm.so
I/DEBUG (30186): #09 pc 00013048 /system/lib/libc.so (__thread_entry)
I/DEBUG (30186): #10 pc 00012b74 /system/lib/libc.so (pthread_create)
I/DEBUG (30186):
I/DEBUG (30186): code around pc:
I/DEBUG (30186): 5a347784 47a868e1 f57f69a0 4620e95c bf00bd7c .h.G.i..\. F|...
I/DEBUG (30186): 5a347794 0036eb46 3088f8d0 bf3a4299 3080f8d0 F.6....0.B:....0
I/DEBUG (30186): 5a3477a4 0021f853 47702000 e005b911 d0034288 S.!.. pG.....B..
I/DEBUG (30186): 5a3477b4 280068c0 e000d1fa 47702001 41f0e92d .h.(..... pG-..A
I/DEBUG (30186): 5a3477c4 f8c54605 460e10a0 f5d62400 4607fa1b .F.....F.$.....F
I/DEBUG (30186):
I/DEBUG (30186): code around lr:
I/DEBUG (30186): 5a229b90 b9084603 e0042001 f8d34620 f6a611a4 .F... .. F......
I/DEBUG (30186): 5a229ba0 bd10fd01 4614b510 2100b14b f11d4618 .......FK..!.F..
I/DEBUG (30186): 5a229bb0 4601fdf3 4620b118 ffe2f7ff 2001e000 ...F.. F.......
I/DEBUG (30186): 5a229bc0 bf00bd10 4ff0e92d 6d464607 460cb0a7 ....-..O.FFm...F
I/DEBUG (30186): 5a229bd0 0b90f10d 0a88f10d 52f4f8d6 f6fa4628 ...........R(F..
I/DEBUG (30186):
I/DEBUG (30186): stack:
I/DEBUG (30186): 5bf04bc8 5bf04c24
I/DEBUG (30186): 5bf04bcc 400828c0 /system/lib/libc.so
I/DEBUG (30186): 5bf04bd0 56d045f8 /dev/ashmem/dalvik-LinearAlloc (deleted)
I/DEBUG (30186): 5bf04bd4 00ffb568 [heap]
I/DEBUG (30186): 5bf04bd8 00000003
I/DEBUG (30186): 5bf04bdc 50fbff00
I/DEBUG (30186): 5bf04be0 5bf04c10
I/DEBUG (30186): 5bf04be4 400827f0 /system/lib/libc.so
I/DEBUG (30186): 5bf04be8 5bf04bf0
I/DEBUG (30186): 5bf04bec 40129393 /system/lib/libutils.so
I/DEBUG (30186): 5bf04bf0 000607dd
I/DEBUG (30186): 5bf04bf4 00000000
I/DEBUG (30186): 5bf04bf8 40eb4a68 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG (30186): 5bf04bfc 40eb4a68 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG (30186): 5bf04c00 df0027ad
I/DEBUG (30186): 5bf04c04 00000000
I/DEBUG (30186): #01 5bf04c08 56e6d840 /dev/ashmem/dalvik-LinearAlloc (deleted)
I/DEBUG (30186): 5bf04c0c 40822db4 /system/lib/libdvm.so
D/PlasmaWebView[1]( 575): Invalidate triggered
I/BootReceiver( 7248): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
I/DEBUG (30186): debuggerd committing suicide to free the zombie!
I/WindowManager( 7248): WIN DEATH: Window{415980d8 com.regaliz.libneo/com.regaliz.libneo.NativeStory paused=false}
I/ActivityManager( 7248): Process com.regaliz.libneo (pid 575) has died.
W/WindowManager( 7248): Force-removing child win Window{416c4f88 SurfaceView paused=false} from container Window{415980d8 com.regaliz.libneo/com.regaliz.libneo.NativeStory paused=false}
I/flint (28979): jni: deleting text normalizer ...
I/flint (28979): jni: deleting synthesizer ...
I/flint (28979): jni: deleting project file ...
I/flint (28979): jni: deleting project resource holder ...
I/DEBUG ( 631): debuggerd: Oct 7 2012 16:35:04
D/Zygote ( 7206): Process 575 terminated by signal (11)
W/ActivityManager( 7248): Force removing ActivityRecord{41303a20 com.regaliz.libneo/.NativeStory}: app died, no saved state
编辑：看起来像我击中的WebKit严重的bug： https：//开头的错误.webkit.org / show_bug.cgi？ID = 93447 。不幸的是其标记为WONTFIX因为谷歌正在远离的WebKit移动到新的渲染引擎眨眼...即时吓到：（
looks like i have hit a critical bug of webkit: https://bugs.webkit.org/show_bug.cgi?id=93447 . Unfortunately its marked as WONTFIX because Google is moving away from webkit into the new rendering engine Blink... im scared :(
编辑2：这是已经报道在Android上的Bug工具与9星，但似乎没有人知道为什么会发生:(的 HTTPS：//$c$c.google.com/p/android/issues/detail ID = 24232
Edit 2: This is already reported on Android Bug Tool with 9 stars, but nobody seems to know why it happens :( https://code.google.com/p/android/issues/detail?id=24232
编辑3：过早打开香槟，但它看起来像的WebView不喜欢带着浓浓的页面加载初始化一个ViewSwitcher和活动视图内部时，他是不是（她/它）自...
Edit 3: Too early to open champagne, but it looks like WebView doesn't like to be initialized with a heavy page load when inside a ViewSwitcher and the active View is not him(her/it)self ...
推荐答案
这是一个有点temerary说，因为其他时间错误出现的早晚，但经过密集调试5天我pretty相信我已经找到灾难的配方。我可以断定：
It's a little temerary to say, because other times the error appeared sooner or later, but after 5 days of intensive debugging I'm pretty sure I have found the recipe for disaster. I can conclude:
把一个一个网页视图里面ViewFlipper和加载在一个复杂的页面
它同时表示其他ViewFlipper页（在我的情况简单
活动指示器）会杀死活动引发了核心转储
Putting a WebView inside a ViewFlipper, and loading a complex page in it, while showing another ViewFlipper page (in my case a simple throbber) would kill the Activity triggering the core dump
我还是保持的WebView在ViewFlipper，但只要初始化期间（页面加载，解析页，body.onload）其viewflipper页面显示，我没有问题。当我重试活动指示器的事情......砰！
I still keep the WebView in the ViewFlipper, but as long as during Init (page load, page parse, body.onload) its viewflipper page is shown, I have no problems. As soon as I retry the throbber thing ... bang!
后，和web视图已趋于稳定，我可以成功改变ViewFlipper意见。
After the page is inited, and webview has stabilized, I can successfully change the ViewFlipper views.
这篇关于的WebView查杀整个活动---如何调试呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
