Windows breakpad no sandbox problem

[Marshall Greenblatt]

Hi All,

When running content_shell on Windows 7 64-bit with breakpad enabled and the sandbox disabled I'm not getting stack trace information [1] for crashes originating from the render process (chrome://crash crashes in the render process):

> content_shell.exe --no-sandbox --enable-crash-reporter chrome://crash

> "c:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\cdb.exe" -v -y C:\chromium\src\build\Debug -c ".ecxr;.lines;k30;q" -z dump.dmp

If I run content_shell in single-process mode, or if the sandbox is enabled, then the resulting stack trace information is correct [2]. Does anyone know how the sandbox interacts with breakpad to generate correct stack traces?

As background, my goal is to support breakpad in Chromium Embedded Framework (CEF) for client application installations where the sandbox is disabled.

Thanks,

Marshall

[1]:

0:000> cdb: Reading initial command '.ecxr;.lines;k30;q'

eax=00000000 ebx=00000001 ecx=fffffff7 edx=00000001 esi=0060d3fc edi=0060ca3c

eip=77bd9f45 esp=0060fa08 ebp=0060fa18 iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

ntdll!RtlInitializeExceptionChain+0x36:

77bd9f45 cc              int     3

Line number information will be loaded

Loading symbols for 77ba0000        ntdll.dll ->   ntdll.dll

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 

ChildEBP RetAddr  

WARNING: Stack unwind information not available. Following frames may be wrong.

0060fa18 00000000 ntdll!RtlInitializeExceptionChain+0x36

[2]:

0:000> cdb: Reading initial command '.ecxr;.lines;k30;q'

eax=00000000 ebx=00000001 ecx=fffffff7 edx=00000001 esi=0037d8e4 edi=0037cf24

eip=030f58e5 esp=0037ccc8 ebp=0037cccc iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

content_shell!content::CrashIntentionally+0x15:

030f58e5 c70000000000    mov     dword ptr [eax],0    ds:002b:00000000=????????

Line number information will be loaded

ChildEBP RetAddr  

0037cccc 030f5750 content_shell!content::CrashIntentionally+0x15 [c:\code\chromium_writable\src\content\renderer\render_view_impl.cc @ 444]

... (other correct stack info)

0037fadc 0080333b content_shell!wWinMain+0x47 [c:\code\chromium_writable\src\content\shell\app\shell_main.cc @ 24]

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for kernel32.dll - 

0037fb6c 7571336a content_shell!__tmainCRTStartup+0x11a [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 275]

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 

WARNING: Stack unwind information not available. Following frames may be wrong.

0037fb78 77bd9f72 kernel32!BaseThreadInitThunk+0x12

0037fbb8 77bd9f45 ntdll!RtlInitializeExceptionChain+0x63

0037fbd0 00000000 ntdll!RtlInitializeExceptionChain+0x36

[Jochen Eisinger]

Since crash dumps in the browser process work, I suspect that some of the non-browser process setup code doesn't work without the sandbox.

However, I have no idea what this is or why this happens :-/

+cdn who might have a clue

best

-jochen

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Marshall Greenblatt]

I'm noticing a similar behavior problem on Linux (Ubuntu 12.04 64-bit). In single-process mode a dmp file is created in the /tmp/crashes directory:

$ ./out/Debug/content_shell --enable-crash-reporter --no-sandbox --single-process --crash-dumps-dir=/tmp/crashes chrome://crash

Segmentation fault (core dumped)

In multi-process mode with the sandbox disabled a stack trace is printed to the console but no dmp file is created:

$ ./out/Debug/content_shell --enable-crash-reporter --no-sandbox --crash-dumps-dir=/tmp/crashes chrome://crash

[2659:2659:1112/174800:207271985:ERROR:renderer_main.cc(227)] Running without renderer sandbox

Received signal 11 SEGV_MAPERR 000000000000

 [0x00000066b280] base::debug::StackTrace::StackTrace()

 [0x00000066ab87] base::debug::(anonymous namespace)::StackDumpSignalHandler()

 [0x7fc614cc1cb0] <unknown>

 [0x00000313c25a] content::CrashIntentionally()

 [0x00000313c320] content::MaybeHandleDebugURL()

 [0x000003144933] content::RenderViewImpl::OnNavigate()

 [0x000003166005] DispatchToMethod<>()

 [0x00000315fa31] ViewMsg_Navigate::Dispatch<>()

 [0x000003142166] content::RenderViewImpl::OnMessageReceived()

 [0x00000396d7f0] content::MessageRouter::RouteMessage()

 [0x00000396d794] content::MessageRouter::OnMessageReceived()

 [0x0000030c9c22] content::ChildThread::OnMessageReceived()

 [0x0000039ff0b4] IPC::ChannelProxy::Context::OnDispatchMessage()

 [0x000003a01892] base::internal::RunnableAdapter<>::Run()

 [0x000003a015c7] base::internal::InvokeHelper<>::MakeItSo()

 [0x000003a01158] base::internal::Invoker<>::Run()

 [0x00000042d57f] base::Callback<>::Run()

 [0x0000005e7b63] base::MessageLoop::RunTask()

 [0x0000005e7c86] base::MessageLoop::DeferOrRunPendingTask()

 [0x0000005e81ab] base::MessageLoop::DoWork()

 [0x0000005f06a0] base::MessagePumpDefault::Run()

 [0x0000005e76e9] base::MessageLoop::RunInternal()

 [0x0000005e75a0] base::MessageLoop::RunHandler()

 [0x00000060d4d8] base::RunLoop::Run()

 [0x0000005e6d66] base::MessageLoop::Run()

 [0x00000318e77e] content::RendererMain()

 [0x00000045fb3d] content::RunZygote()

 [0x00000045fd8b] content::RunNamedProcessTypeMain()

 [0x000000460e86] content::ContentMainRunnerImpl::Run()

 [0x00000045f1cb] content::ContentMain()

 [0x0000004234b5] main

 [0x7fc613a8676d] __libc_start_main

 [0x0000004233c9] <unknown>

  r8: 000000000000007c  r9: 0000000000c00000 r10: 0000000000000000 r11: 00007fc613af13f0

 r12: 000000000043d780 r13: 00007fff040b2370 r14: 0000000000000000 r15: 0000000000000000

  di: 00007fff040ae15c  si: 0000000000000000  bp: 00007fff040adf80  bx: 0000000000000001

  dx: 0000000000000513  ax: 0000000000000000  cx: 0000000000000076  sp: 00007fff040adf80

  ip: 000000000313c25a efl: 0000000000010202 cgf: 0000000000000033 erf: 0000000000000006

 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000

[Lei Zhang]

Does reverting r233553 make a difference for you? I just noticed on
Linux, with newer 'official' Chrome builds, Linux crash reporting
isn't uploading anything.

On Tue, Nov 12, 2013 at 2:58 PM, Marshall Greenblatt

[Marshall Greenblatt]

On Tue, Nov 12, 2013 at 6:09 PM, Lei Zhang <the...@chromium.org> wrote:

Does reverting r233553 make a difference for you? I just noticed on
Linux, with newer 'official' Chrome builds, Linux crash reporting
isn't uploading anything.

Nope, same behavior with this change reverted.