1

the code block below is the crash stack of a iOS APP, which using Cronet.

we are trying to find the exact crash line in the source code according to the last frame 1,

as we can see, is the function of insert, but it was not called directly in frame2 (EntryImply::InternalWriteData),

rather called in the function EntryImpl::UserBuffer::Write, which was called in frame2,

but the Write function was not appeared in the crash stack,

is it possible the lldb treat the Write as a inline function?

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
Berte Colin
  • 65
  • 7
  • 1
    I'm not sure why this was considered off-topic. They have a crash log for a crash in a C++ program, the crash log doesn't show inline stack frames, and they are asking how to retrieve the inline frame information. This is a super-common question (that's why there was a whole WWDC session on it in 2018). I think they were a little confused and thought lldb was producing the crash log (it wasn't). But other than that the question was quite clear. – Jim Ingham Nov 22 '19 at 02:21

1 Answers1

2

This is not an lldb backtrace, this is from a CrashReport, right? lldb doesn't process CrashReports, that's the job of a component called CoreSymbolication, which doesn't currently handle inlined code. It also looks like CoreSymbolication couldn't find the dSYM for this binary at the time of the crash, or you would at least see file & line numbers for the non-inlined frames.

lldb does understand inlined code, and will always show inlined frame stacks in the backtrace. Provided you have the dSYM's on hand, you can use lldb to symbolicate crashes after the fact. There was a WWDC session on this topic in 2018 that you might find useful:

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

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63