Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

stripped binaries produce useless backtraces #514

Closed
mspang opened this issue Jan 7, 2020 · 0 comments · Fixed by #513
Closed

stripped binaries produce useless backtraces #514

mspang opened this issue Jan 7, 2020 · 0 comments · Fixed by #513
Milestone
0.5

Comments

@mspang
Copy link
Contributor

mspang commented Jan 7, 2020 •
edited
Loading

Symbolize falls back to file offsets for binaries that cannot be open for read. However, binaries that can be opened but have no symbols will fail symbolization completely even though we could use the file offsets in this case.

Failing completely produces unusable backtraces in chromium as the base address isn't known, e.g.

    Received signal 11 SEGV_MAPERR 000000000000
    #0 0x560e135956b9 <unknown>
    #1 0x560e134a91f3 <unknown>
    #2 0x560e13595171 <unknown>
    #3 0x7f0c97ef03a0 <unknown>
    #4 0x560e18cfe6b0 <unknown>
    #5 0x560e18bd304b <unknown>
    #6 0x560e18be9347 <unknown>
    #7 0x560e0fbfbaee <unknown>
    #8 0x560e136e540f <unknown>
    #9 0x560e136ebedb <unknown>
    #10 0x560e136e6b95 <unknown>
    #11 0x560e141c36cf <unknown>
    #12 0x560e141c37dc <unknown>
    #13 0x560e13514992 <unknown>
    #14 0x560e13530944 <unknown>
    #15 0x560e1353061e <unknown>
    #16 0x560e134ca904 <unknown>
    #17 0x560e13531357 <unknown>
    #18 0x560e134f5b27 <unknown>
    #19 0x560e195304c0 <unknown>
    #20 0x560e12f001c9 <unknown>
    #21 0x560e12f017fe <unknown>
    #22 0x560e12f526dd <unknown>
    #23 0x560e12eff521 <unknown>
    #24 0x560e0f53a5fd ChromeMain
    #25 0x7f0c94e0552b __libc_start_main
    #26 0x560e0f53a32a _start

If we allow the fallback to file offsets in this case we'd instead get the following:

    Received signal 11 SEGV_MAPERR 000000000000
    #0 0x564771f446f9 (/ssd/src/chromium/src/out/linux_rel/chrome+0x72966f8)
    #1 0x564771e58233 (/ssd/src/chromium/src/out/linux_rel/chrome+0x71aa232)
    #2 0x564771f441b1 (/ssd/src/chromium/src/out/linux_rel/chrome+0x72961b0)
    #3 0x7f0545ac33a0 (/lib/x86_64-linux-gnu/libpthread-2.28.so+0x1239f)
    #4 0x5647776ad7d0 (/ssd/src/chromium/src/out/linux_rel/chrome+0xc9ff7cf)
    #5 0x56477758216b (/ssd/src/chromium/src/out/linux_rel/chrome+0xc8d416a)
    #6 0x564777598467 (/ssd/src/chromium/src/out/linux_rel/chrome+0xc8ea466)
    #7 0x56476e5aab2e (/ssd/src/chromium/src/out/linux_rel/chrome+0x38fcb2d)
    #8 0x56477209452f (/ssd/src/chromium/src/out/linux_rel/chrome+0x73e652e)
    #9 0x56477209affb (/ssd/src/chromium/src/out/linux_rel/chrome+0x73ecffa)
    #10 0x564772095cb5 (/ssd/src/chromium/src/out/linux_rel/chrome+0x73e7cb4)
    #11 0x564772b727ef (/ssd/src/chromium/src/out/linux_rel/chrome+0x7ec47ee)
    #12 0x564772b728fc (/ssd/src/chromium/src/out/linux_rel/chrome+0x7ec48fb)
    #13 0x564771ec39d2 (/ssd/src/chromium/src/out/linux_rel/chrome+0x72159d1)
    #14 0x564771edf984 (/ssd/src/chromium/src/out/linux_rel/chrome+0x7231983)
    #15 0x564771edf65e (/ssd/src/chromium/src/out/linux_rel/chrome+0x723165d)
    #16 0x564771e79944 (/ssd/src/chromium/src/out/linux_rel/chrome+0x71cb943)
    #17 0x564771ee0397 (/ssd/src/chromium/src/out/linux_rel/chrome+0x7232396)
    #18 0x564771ea4b67 (/ssd/src/chromium/src/out/linux_rel/chrome+0x71f6b66)
    #19 0x564777edf5e0 (/ssd/src/chromium/src/out/linux_rel/chrome+0xd2315df)
    #20 0x5647718af209 (/ssd/src/chromium/src/out/linux_rel/chrome+0x6c01208)
    #21 0x5647718b083e (/ssd/src/chromium/src/out/linux_rel/chrome+0x6c0283d)
    #22 0x56477190171d (/ssd/src/chromium/src/out/linux_rel/chrome+0x6c5371c)
    #23 0x5647718ae561 (/ssd/src/chromium/src/out/linux_rel/chrome+0x6c00560)
    #24 0x56476dee963d ChromeMain
    #25 0x7f05429d852b __libc_start_main
    #26 0x56476dee936a _start

Which can be symbolized with asan_symbolize.py to get:

Received signal 11 SEGV_MAPERR 000000000000
#0 0x564771f446f9 in base::debug::CollectStackTrace(void**, unsigned long) ./../../base/debug/stack_trace_posix.cc:840:39
#1 0x564771e58233 in StackTrace ./../../base/debug/stack_trace.cc:206:12
#2 0x564771e58233 in base::debug::StackTrace::StackTrace() ./../../base/debug/stack_trace.cc:203:28
#3 0x564771f441b1 in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) ./../../base/debug/stack_trace_posix.cc:345:3
#4 0x7f0545ac33a0 in __funlockfile ??:?
#5 0x7f0545ac33a0 in ?? ??:0
#6 0x5647776ad7d0 in content::internal::CrashIntentionally() ./../../content/renderer/crash_helpers.cc:20:3
#7 0x56477758216b in content::HandleChromeDebugURL(GURL const&) ./../../content/renderer/render_frame_impl.cc:1190:5
#8 0x564777598467 in content::RenderFrameImpl::HandleRendererDebugURL(GURL const&) ./../../content/renderer/render_frame_impl.cc:3754:5
#9 0x56476e5aab2e in content::mojom::FrameNavigationControlStubDispatch::Accept(content::mojom::FrameNavigationControl*, mojo::Message*) ./gen/content/common/frame.mojom.cc:2440:13
#10 0x56477209452f in mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) ./../../mojo/public/cpp/bindings/lib/interface_endpoint_client.cc:554:54
#11 0x56477209affb in mojo::MessageDispatcher::Accept(mojo::Message*) ./../../mojo/public/cpp/bindings/lib/message_dispatcher.cc:41:19
#12 0x564772095cb5 in mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) ./../../mojo/public/cpp/bindings/lib/interface_endpoint_client.cc:356:22
#13 0x564772b727ef in IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread(mojo::Message) ./../../ipc/ipc_mojo_bootstrap.cc:933:24
#14 0x564772b728fc in Invoke<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message), scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>, mojo::Message> ./../../base/bind_internal.h:499:12
#15 0x564772b728fc in MakeItSo<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message), scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>, mojo::Message> ./../../base/bind_internal.h:599:12
#16 0x564772b728fc in RunImpl<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message), std::__1::tuple<scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>, mojo::Message>, 0, 1> ./../../base/bind_internal.h:672:12
#17 0x564772b728fc in base::internal::Invoker<base::internal::BindState<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message), scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>, mojo::Message>, void ()>::RunOnce(base::internal::BindStateBase*) ./../../base/bind_internal.h:641:12
#18 0x564771ec39d2 in Run ./../../base/callback.h:98:12
#19 0x564771ec39d2 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/task/common/task_annotator.cc:142:33
#20 0x564771edf984 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:365:23
#21 0x564771edf65e in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:219:7
#22 0x564771e79944 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./../../base/message_loop/message_pump_default.cc:39:55
#23 0x564771ee0397 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) ./../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:463:12
#24 0x564771ea4b67 in base::RunLoop::Run() ./../../base/run_loop.cc:155:14
#25 0x564777edf5e0 in content::RendererMain(content::MainFunctionParams const&) ./../../content/renderer/renderer_main.cc:213:16
#26 0x5647718af209 in content::RunZygote(content::ContentMainDelegate*) ./../../content/app/content_main_runner_impl.cc:501:14
#27 0x5647718b083e in content::ContentMainRunnerImpl::Run(bool) ./../../content/app/content_main_runner_impl.cc:880:10
#28 0x56477190171d in service_manager::Main(service_manager::MainParams const&) ./../../services/service_manager/embedder/main.cc:423:29
#29 0x5647718ae561 in content::ContentMain(content::ContentMainParams const&) ./../../content/app/content_main.cc:19:10
#24 0x56476dee963d ChromeMain
#25 0x7f05429d852b __libc_start_main
#26 0x56476dee936a _start

Fixing this would be a huge help to projects that must deploy stripped binaries due to space constraints (e.g. Chromecast, Chrome OS).
@mspang mspang mentioned this issue Jan 7, 2020
Merged
@mspang mspang changed the title stripped binaries produces useless backtraces stripped binaries produce useless backtraces Jan 8, 2020
@ukai ukai closed this as completed in #513 Jan 8, 2020
ukai pushed a commit that referenced this issue Jan 8, 2020
@mspang @ukai
Use file offsets in traces if object has no symbols (#513)
130a3e1 
Fallback to using file offsets if no symbol is found, like we do if the
object could not be opened.

This makes backtraces usable even if objects in the trace are stripped,
since the trace can be symbolized by post-processing it with a tool like
asan_symbolize.py.

Note that this is not currently compatible with SymbolizeCallback as
this overwrites the filename in the buffer. The behavior is unchanged
in that case.

Closes: #514
@sergiud sergiud added this to the 0.5 milestone Mar 30, 2021
@sergiud sergiud mentioned this issue May 6, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.5
Development

Successfully merging a pull request may close this issue.

Use file offsets in traces if object has no symbols
2 participants
@mspang @sergiud