Microdump crashes when there is renderer process crash |
|||
Issue descriptionSpin off from crbug.com/613780. Reproduction step is there too. Is this LOG(FATAL) expected? 05-21 02:31:43.339 1140 1161 F chromium: [FATAL:crash_micro_dump_manager_android.cc(81)] Renderer process crash detected (code 11). Terminating browser. The crash stack is as follows: Operating system: Android google/shamu/shamu:N/NRD28D/2823836:userdebug/dev-keys CPU: arm 4 CPUs GPU: OpenGL ES 3.2 V@145.0 (GIT@If8245c9ceb) Qualcomm Adreno (TM) 420 Crash reason: Crash address: 0x0 Process uptime: not available Thread 0 (crashed) 0 libc.so + 0x49d50 r0 = 0x00000000 r1 = 0x00000489 r2 = 0x00000006 r3 = 0x00000008 r4 = 0x8fa80978 r5 = 0x00000006 r6 = 0x8fa80920 r7 = 0x0000010c r8 = 0xac7b6008 r9 = 0x8fa80564 r10 = 0x00000000 r12 = 0x00000002 fp = 0x97691808 sp = 0x8fa800b0 lr = 0xac7714e7 pc = 0xac773d50 Found by: given as instruction pointer in context 1 libc.so + 0x1d5f7 sp = 0x8fa800c8 pc = 0xac7475f9 Found by: stack scanning 2 libc.so + 0x19143 sp = 0x8fa800d0 pc = 0xac743145 Found by: stack scanning 3 libc.so + 0x1700a sp = 0x8fa800f8 pc = 0xac74100c Found by: stack scanning 4 libwebviewchromium.so!base::debug::BreakDebugger [debugger_posix.cc : 219 + 0x3] sp = 0x8fa80100 pc = 0x9724e275 Found by: stack scanning 5 libwebviewchromium.so!logging::LogMessage::~LogMessage [logging.cc : 740 + 0x3] r3 = 0x97af936c sp = 0x8fa80108 pc = 0x97257d29 Found by: call frame info 6 libwebviewchromium.so!breakpad::CrashMicroDumpManager::HandleChildTerminationOnFileThread [crash_micro_dump_manager_android.cc : 81 + 0x5] r4 = 0x8fa8055c r5 = 0xac51ff38 r6 = 0xa51a3268 r7 = 0xac7b6008 r8 = 0xac51ff48 r9 = 0x00000005 r10 = 0x0c0c0c10 sp = 0x8fa80550 pc = 0x9722ada5 Found by: call frame info 7 libwebviewchromium.so!base::internal::Invoker<base::IndexSequence<0u, 1u, 2u>, base::internal::BindState<base::internal::RunnableAdapter<void (breakpad::CrashMicroDumpManager::*)(int, base::TerminationStatus)>, void(breakpad::CrashMicroDumpManager*, int, base::TerminationStatus), base::WeakPtr<breakpad::CrashMicroDumpManager>, int, base::TerminationStatus&>, base::internal::InvokeHelper<true, void, base::internal::RunnableAdapter<void (breakpad::CrashMicroDumpManager::*)(int, base::TerminationStatus)> >, void()>::Run [bind_internal.h : 186 + 0x5] r4 = 0x9722aca9 r5 = 0x8fd7e120 r6 = 0x8fa80618 r7 = 0x97afa41a r8 = 0xac560f20 r9 = 0x00000000 r10 = 0x0c0c0c10 sp = 0x8fa80618 pc = 0x96394c1f Found by: call frame info 8 libwebviewchromium.so!base::debug::TaskAnnotator::RunTask [callback.h : 397 + 0x5] r4 = 0x8fa807c0 r5 = 0x8fa806a8 r6 = 0x8fa806a0 r7 = 0x97afa41a r8 = 0xac560f20 r9 = 0x00000000 r10 = 0x0c0c0c10 sp = 0x8fa80638 pc = 0x9724e3e3 Found by: call frame info 9 libwebviewchromium.so!base::MessageLoop::RunTask [message_loop.cc : 478 + 0xd] r4 = 0x8fa807c0 r5 = 0xac560e60 r6 = 0x97afa410 r7 = 0x97afa390 r8 = 0x975ca279 r9 = 0x8fa807c8 r10 = 0x0c0c0c10 fp = 0x0000000c sp = 0x8fa806f8 pc = 0x9725ae81 Found by: call frame info 10 libwebviewchromium.so!base::MessageLoop::DeferOrRunPendingTask [message_loop.cc : 487 + 0x7] r4 = 0xac560e60 r5 = 0x00000001 r6 = 0x8fa807c0 r7 = 0xac560e6c r8 = 0x8fa807d0 r9 = 0x8fa807c8 r10 = 0x0c0c0c10 fp = 0x0000000c sp = 0x8fa807a0 pc = 0x9725b317 Found by: call frame info 11 libwebviewchromium.so!base::MessageLoop::DoWork [message_loop.cc : 604 + 0x3] r3 = 0x00000000 r4 = 0xac560e60 r5 = 0x8fa807c0 r6 = 0xc0c0c0c1 r7 = 0xac560e6c r8 = 0x8fa807d0 r9 = 0x8fa807c8 r10 = 0x0c0c0c10 fp = 0x0000000c sp = 0x8fa807c0 pc = 0x9725b5a9 Found by: call frame info 12 libwebviewchromium.so!base::MessagePumpLibevent::Run [message_pump_libevent.cc : 217 + 0x7] r4 = 0xa51ae228 r5 = 0xac560e60 r6 = 0xa51ae230 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xa51bc410 r10 = 0x9725c5d5 fp = 0x00000002 sp = 0x8fa80818 pc = 0x9725c503 Found by: call frame info 13 libwebviewchromium.so!base::RunLoop::Run [run_loop.cc : 35 + 0x5] r4 = 0x8fa80890 r5 = 0x8fa8086c r6 = 0x8fb86288 r7 = 0xac560e60 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa80868 pc = 0x9726826d Found by: call frame info 14 libwebviewchromium.so!base::MessageLoop::Run [message_loop.cc : 294 + 0x5] r4 = 0x8fb86280 r5 = 0xac560e60 r6 = 0x8fb86288 r7 = 0xac560e60 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa80890 pc = 0x9725a6ed Found by: call frame info 15 libwebviewchromium.so!content::BrowserThreadImpl::FileThreadRun [browser_thread_impl.cc : 188 + 0x3] r4 = 0x8fb86280 r5 = 0xac560e60 r6 = 0x8fb86288 r7 = 0xac560e60 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa808b0 pc = 0x962f47cb Found by: call frame info 16 libwebviewchromium.so!content::BrowserThreadImpl::Run [browser_thread_impl.cc : 243 + 0x5] r4 = 0x8fb86280 r5 = 0xac560e60 r6 = 0x8fb86288 r7 = 0xac560e60 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa808c0 pc = 0x962f4895 Found by: call frame info 17 libwebviewchromium.so!base::Thread::ThreadMain [thread.cc : 254 + 0x5] r4 = 0x8fb86280 r5 = 0xac7b6008 r6 = 0x8fb86288 r7 = 0xac560e60 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa808d8 pc = 0x9727969b Found by: call frame info 18 libwebviewchromium.so!ThreadFunc [platform_thread_posix.cc : 70 + 0x7] r4 = 0x8fa80920 r5 = 0x8fb86280 r6 = 0xa00b8020 r7 = 0x00000078 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa80900 pc = 0x972771e5 Found by: call frame info 19 libc.so + 0x46fb3 r4 = 0x8fa80920 r5 = 0xac770f9d r6 = 0x8fa80920 r7 = 0x00000078 r8 = 0xbe849f1c r9 = 0x8fb930c0 r10 = 0x972771b1 fp = 0x00000002 sp = 0x8fa80910 pc = 0xac770fb5 Found by: call frame info 20 libc.so + 0x19b9d sp = 0x8fa80918 pc = 0xac743b9f Found by: stack scanning 21 libwebviewchromium.so!base::PlatformThread::SetCurrentThreadPriority(base::ThreadPriority) + 0x22 sp = 0x8fa80954 pc = 0x972771b1 Found by: stack scanning
,
May 24 2016
The user shouldn't see two crash dialogs - the renderer is a background process, which don't display crash dialogs on user builds, only debug. Maybe test on user to verify this? We don't have any real control over much of this - we could _exit the entire process after breakpad generates the microdump in the renderer, but that would skip the debuggerd crash output entirely as well as the system crash dialog (those are both a single step inside debuggerd). I'm not sure any approach is going to work too well here with the current system behaviour and crash pipeline. If we skip the crash dialog in the renderer, then a user who reports the crash when the browser crashes is going to be sending a report that only includes the debuggerd info for the browser process - if we're lucky then both microdumps will still be in the log, but we don't have any automated process to know which one "matters". It might be that the only sensible way to handle renderer process crashes is to upload them ourselves and not rely on feedback at all :/
,
May 24 2016
One thing we could try to do to make this a bit less broken is crash the browser process in java instead, which would at least avoid the microdump/debuggerd output and make the log easier to understand, but there's not an easy way to *do* that in a timely manner - this is the file thread it looks like, which is a native thread and so can't return with an exception to the VM. :(
,
May 24 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 21 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by hush@chromium.org
, May 24 2016