没有被调用函数的奇怪的iOS崩溃堆栈[关闭]答案

【问题标题】：Weird iOS crash stack without the called function [closed]没有被调用函数的奇怪的iOS崩溃堆栈[关闭]
【发布时间】：2019-11-20 06:02:15
【问题描述】：

下面的代码块是一个 iOS APP 的崩溃堆栈，它使用了 Cronet。

我们正在尝试根据最后一帧在源代码中找到确切的崩溃行，

我们可以看到，是insert的函数，但不是直接在frame2中调用的(EntryImply::InternalWriteData)，

而是在函数EntryImpl::UserBuffer::Write中调用，在frame2中调用，

但是Write函数没有出现在崩溃堆栈中，

lldb 是否可以将 Write 视为内联函数？

here is the source code of Write and InternalWriteData.

#19. Crashed: CacheThread_BlockFile
SIGSEGV 0x00000001242e57f7
0  libsystem_platform.dylib       0x22d376de4 _platform_memmove + 164
1  Meipai                         0x103f2ec18 
std::__1::enable_if<(__is_forward_iterator<char*>::value) && (is_constructible<char, ```
std::__1::iterator_traits<char*>::reference>::value), std::__1::__wrap_iter<char*> >::type std::__1::vector<char, std::__1::allocator<char> >::insert<char*>(std::__1::__wrap_iter<char const*>, char*, char*) + 18623032
2  Meipai                         0x103f2f7b0 disk_cache::EntryImpl::InternalWriteData(int, int, net::IOBuffer*, int, base::OnceCallback<void (int)>, bool) + 18626000
3  Meipai                         0x103f2f5bc disk_cache::EntryImpl::WriteDataImpl(int, int, net::IOBuffer*, int, base::OnceCallback<void (int)>, bool) + 18625500
4  Meipai                         0x103f3b56c disk_cache::SparseControl::DoChildIO() + 18674572
5  Meipai                         0x103f3a67c disk_cache::SparseControl::DoChildrenIO() + 18670748
6  Meipai                         0x103f3a630 disk_cache::SparseControl::StartIO(disk_cache::SparseControl::SparseOperation, long long, net::IOBuffer*, int, base::OnceCallback<void (int)>) + 18670672
7  Meipai                         0x103f2fc88 disk_cache::EntryImpl::WriteSparseDataImpl(long long, net::IOBuffer*, int, base::OnceCallback<void (int)>) + 18627240
8  Meipai                         0x103f355e8 disk_cache::BackendIO::ExecuteEntryOperation() + 18650120
9  Meipai                         0x103e509c4 base::TaskAnnotator::RunTask(char const*, base::PendingTask*) + 17713124
10 Meipai                         0x103e5ffc0 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) + 17776096
11 Meipai                         0x103e60408 non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() + 17777192
12 Meipai                         0x103eba4c8 base::MessagePumpCFRunLoopBase::RunWork() + 18146024

【问题讨论】：

我不确定为什么这被认为是题外话。他们有一个 C++ 程序崩溃的崩溃日志，崩溃日志不显示内联堆栈帧，他们询问如何检索内联帧信息。这是一个非常常见的问题（这就是为什么在 2018 年有一个完整的 WWDC 会议）。我认为他们有点困惑，并认为 lldb 正在生成崩溃日志（不是）。但除此之外，问题很明确。

标签： c++ inline compiler-optimization lldb cronet

【解决方案1】：

这不是 lldb 回溯，这是来自 CrashReport，对吗？ lldb 不处理 CrashReports，这是一个名为 CoreSymbolication 的组件的工作，该组件当前不处理内联代码。看起来 CoreSymbolication 在崩溃时找不到此二进制文件的 dSYM，或者您至少会看到非内联帧的文件和行号。

lldb 确实理解内联代码，并且总是会在回溯中显示内联帧堆栈。如果您手头有 dSYM，则可以在事后使用 lldb 来表示崩溃。 2018 年有一个关于这个主题的 WWDC 会议，您可能会觉得有用：

https://developer.apple.com/videos/play/wwdc2018/414/

【讨论】：

对，它来自 CrashReport，非常感谢您的有效回答。