Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
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
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/
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed last month.
Improve this question
I get a segfault related to the following line:
int testenum = atoi(argv[1]);
The following is the whole error:
/build/bin/wrapper' has changed; re-reading symbols.
Temporary breakpoint 5 at 0x13f5: file /examples/wrapper.cpp, line 166.
Starting program: /build/bin/wrapper
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Temporary breakpoint 5, main (argc=1, argv=0x7fffffffe288) at /examples/wrapper.cpp:166
166 testenum = atoi(argv[1]);
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6fffa3b in __GI_____strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=<optimized out>, loc=0x7ffff71934a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:291
291 while (ISSPACE (*s))
(gdb) backtrace
#0 0x00007ffff6fffa3b in __GI_____strtol_l_internal (nptr=0x0,
endptr=0x0, base=10, group=<optimized out>,
loc=0x7ffff71934a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:291
#1 0x0000555555555405 in atoi (
__nptr=0xa <error: Cannot access memory at address 0xa>)
at /usr/include/stdlib.h:364
#2 main (argc=<optimized out>, argv=0x7fffffffe288)
at /examples/wrapper.cpp:166
(gdb)
Why does this seemingly simple line trigger this error in GDB, when it runs seemingly fine when ran traditionally?
The message tells you exactly what the error is:
0x00007ffff6fffa3b in __GI_____strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=<optimized out>, loc=0x7ffff71934a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:291
Translation: The error happened while converting a string to long, the input string pointer (nptr) is NULL.
Since this line of code attempts to convert a string to long
int testenum = atoi(argv[1]);
This means argv[1] is NULL. You failed to check before passing command line arguments to atoi() that the user actually passed arguments to the program when launching it from the command line.
Use main function parameter argc to check if the user passed arguments to the program. To use argv[1], then you should have argc > 1, otherwise your program will crash and will print the error message above.
I'm trying to step through this:
fn main() {
println!("Hello {}", 0);
}
I've tried compiling with both: cargo build and rustc -g -L src/main.rs
I then run gdb target/debug/rust-gdb-test (or gdb main), and try to set a breakpoint on main with break main.
(break ::rust-gdb-test::main returns Function "::rust-gdb-test" not defined.).
After breaking (Breakpoint 1, 0x0000555555559610 in main ()) if I try to run list, I get:
1 dl-debug.c: No such file or directory.
I am running Rust 1.10.0 (cfcb716cf 2016-07-03) and GDB 7.7.1 (Debian 7.7.1+dfsg-5).
A similar question was asked 2 years ago, but I couldn't make the solutions presented there to work.
Note: I seem to not have GDB installed anymore, only LLDB, but for this question the answer is the same.
The main that you see in Rust is not the same main that exists in the compiled binary. Specifically, there are a number of shim methods between the two. The Rust main actually includes the crate name (in my example buggin) and a hash (in my case hfe08615ed561bb88):
* frame #0: 0x000000010000126d buggin`buggin::main::hfe08615ed561bb88 + 29 at main.rs:2
frame #1: 0x000000010000810e buggin`std::panicking::try::call::hbbf4746cba890ca7 + 30
frame #2: 0x000000010000aadc buggin`__rust_try + 12
frame #3: 0x000000010000aa76 buggin`__rust_maybe_catch_panic + 38
frame #4: 0x0000000100007f32 buggin`std::rt::lang_start::hbcefdc316c2fbd45 + 562
frame #5: 0x00000001000013aa buggin`main + 42
frame #6: 0x00007fff910435ad libdyld.dylib`start + 1
frame #7: 0x00007fff910435ad libdyld.dylib`start + 1
Here, you can see that main is a few frames away in the stack.
I tend to use a wildcard breakpoint to not deal with the hash:
(lldb) br set -r 'buggin::main.*'
Breakpoint 5: where = buggin`buggin::main::hfe08615ed561bb88 + 29, address = 0x000000010000126d
rbreak should be an equivalent in GDB.
Once the program is stopped, you should be able to see the source. You may also be interested in the rust-lldb and rust-gdb wrappers that ship with Rust and improve the experience a bit.
This is basically the same as this answer, but mentions the hash.
Neither (gdb) rbreak 'rust-gdb-test::main.*' nor (lldb) br set -r 'rust-gdb-test::main.*' set any breakpoints for me.
The hyphen (-) is not a valid symbol character. When compiled, it is converted to an underscore.
My original methodology was actually this:
(lldb) br set -r '.*main.*'
Breakpoint 2: 67 locations.
You can then run the program and continue a few times until you find the right place. Don't be afraid to get in there and explore a bit; it's just a debugger!
You could try various versions of the regex to see if anything interesting might match:
(lldb) br set -r '.*main::.*'
Breakpoint 3: where = rust-gdb-test`rust_gdb_test::main::h97d2ac6fea75a245 + 29,
(lldb) br set -r '.*::main.*'
Breakpoint 4: where = rust-gdb-test`rust_gdb_test::main::h97d2ac6fea75a245 + 29,
You could also call a function with a very unique name from main and set a breakpoint on that:
(lldb) br set -r '.*a_really_unique_name.*'
I've been coding a game for the past year, I'm in the process of porting to Mac.
I've set everything up according to: http://blog.davidecoppola.com/2013/08/22/how-to-set-up-a-sdl-2-project-for-os-x-in-xcode-4/. I have changed some of the steps to compensate for the version (5).
In my code I use tinyXML to load a .xml file within an assets folder. This works perfectly on windows and linux, however, in Mac I experience some issues. Here's the line:
Doc.LoadFile(DataPath);
Doc is a tinyxml2::XMLDocument type, and the DataPath is usually "assets/Data.xml", in Mac I hard-coded that line into the place of "DataPath".
When running the code within the IDE I experience no issues and my game comes up and plays like it does on all other platforms, however, when running the .app file (Located in gameMac/Build/Products/Debug) it crashes right after starting up. The Assets folder is also located in this location.
Here's the error Mac throws at me after the crash:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 gameMac 0x000c1525 tinyxml2::XMLNode::FirstChildElement(char const*) const + 21
1 gameMac 0x000d1954 tinyxml2::XMLNode::FirstChildElement(char const*) + 36
2 gameMac 0x000d04d5 DataLoader::load(char const*, ID_Data, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 197
3 gameMac 0x000a5849 MapHandler::MapHandler(std::__1::shared_ptr<gameData>) + 1177
4 gameMac 0x000a539e MapHandler::MapHandler(std::__1::shared_ptr<gameData>) + 30
5 gameMac 0x000b7eb8 splay::splay(std::__1::shared_ptr<gameData>) + 1592
6 gameMac 0x000b786e splay::splay(std::__1::shared_ptr<gameData>) + 30
7 gameMac 0x000ee3f9 std::__1::shared_ptr<splay> std::__1::shared_ptr<splay>::make_shared<std::__1::shared_ptr<gameData>&>(std::__1::shared_ptr<gameData>&&&) + 1849
8 gameMac 0x000ebc7c stateHandlerGen::stateHandlerGen(std::__1::shared_ptr<gameData>) + 236
9 gameMac 0x000ebb7e stateHandlerGen::stateHandlerGen(std::__1::shared_ptr<gameData>) + 30
10 gameMac 0x000e7a89 game::init(char const*, int, int, int, int, bool) + 1545
11 gameMac 0x000be8c4 main + 516
12 libdyld.dylib 0x91b3c725 start + 1
(Please note that gameMac is not the name of my project, I have changed that detail due to an NDA).
As I've noted here, the same method that loads my data DataLoader::load(params) is giving the crash. This leads me to believe that my assets folder is not being loaded into my .app file.
Through this I attempted to edit a Build Phase, Copy Bundle Resources this did not change the issue. I then attempted to make a New Build Phase Copy Files and set it to Resources, this also failed. I then experimented by setting the Copy Files to Product Directory; this copied the assets folder to the build folder, but the .app file still won't load in the assets.
Did I miss something? Could some XCode vets help me out here, I've attempted to fix this for the past few days. Thanks.
http://pastebin.com/Xq4Hxh4d (Here's the top of my DataLoader as mentioned above. EDIT: Added in my check for nullptr return, yes, it returns true if failed).
P.S I can only give out snippets of my code, I have given what I feel is most likely the problem, resource loading :)
The full crash report is in the comments below.
The fix, thanks to the help from Brad Allred:
The resources are located within the .app file, specifically {Application}/Contents/Resources ; in my case I wanted to access a file within assets. I did a build phase to copy the data to the resources folder, making my directory {Application}/Contents/Resources/Assets/../. Using SDL_GetBasePath I'm able to create a string which is the absolute path from your base directory up to the Resources folder.
Here's the code:
if(Doc.LoadFile("assets/Data.xml"))
{
std::string path = (std::string)SDL_GetBasePath() + "assets/Data.xml";
if(Doc.LoadFile(path.c_str()))
{
return false;
}
}
I concat the base path + whatever data I need, and pass the .c_str() version to tinyXML. If I find a better/cleaner version I'll be sure to update it here.
your crash report tells you the line number in your code that is crashing (tinyxml2.cpp:745). at Probably your assets are not where the app expects them to be or doesnt have permission. examining your DataPath to see where its trying to load should get you started.
It seems like maybe you are mistakenly assuming that you can use a relative path and get assets relative to the app bundle; you can't do that.
Since you are using SDL, why not use the SDL API (see SDL_GetBasePath) to get resource paths so that you can store your assets properly inside your app bundle in the Resources directory?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have observed a core dump on a UNIX server and have to analyze the cause behind it.
Following is the output of coredump using mdb
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> ::status
debugging core file of pmr_colld_aos (32-bit) from atrcxb2532
file: /opt/ericsson/aos/PDM/bin/pmr_colld_aos
initial argv: /opt/ericsson/aos/PDM/bin/pmr_colld_aos -ORBInitRef NameService=corbaloc::maste
threading model: multi-threaded
status: process terminated by SIGABRT (Abort)
> ::stack
libc.so.1`_lwp_kill+0x15(1, 6)
libc.so.1`raise+0x1f(6)
libc.so.1`abort+0xcd(8026ad0, 8eb2d88, 0, fe2cb9d0, 8ea9f50, 80275b0)
libstdc++.so.6.0.3`_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xdf(fe2eb0c0, fe2cb9d0, 8026a78, fe2b53cc, fe2b7298, 8ea9f50)
libstdc++.so.6.0.3`_ZN10__cxxabiv111__terminateEPFvvE+0x14(fe2b7298, 8ea9f50, 8026a88, fe2b467a, feffd888, fe2cb9d0)
libstdc++.so.6.0.3`_ZN10__cxxabiv112__unexpectedEPFvvE(1, fe2cb9d0, 8026af8, fe2b52d6, fe2b53ac, fe217a44)
libstdc++.so.6.0.3`_ZN10__cxxabiv112__unexpectedEPFvvE+0x14(fe2b53ac, fe217a44, feffa320, 0, 8026ad8, fe2b7298)
libstdc++.so.6.0.3`__cxa_call_unexpected+0x42(8ea9f80, 8026b40, 8c70120, 82aa448, 8e382a8, 8026b20)
_ZN21PDRFileTimeoutHandler5checkEv+0xa10(fe17f000, fdfa2a00, 8026c90, fe0a5bf6, fe180680, 0)
main+0x1309(2, 8026e10, 8026e24)
_start+0x80(4, 8027618, 8027682, 802764c, 8027640, 0)
> $C
080269c4 libc.so.1`_lwp_kill+0x15(1, 6)
080269dc libc.so.1`raise+0x1f(6)
08026a28 libc.so.1`abort+0xcd(8026ad0, 8eb2d88, 0, fe2cb9d0, 8ea9f50, 80275b0)
08026a48 libstdc++.so.6.0.3`_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xdf(fe2eb0c0, fe2cb9d0, 8026a78, fe2b53cc, fe2b7298, 8ea9f50)
08026a58 libstdc++.so.6.0.3`_ZN10__cxxabiv111__terminateEPFvvE+0x14(fe2b7298, 8ea9f50, 8026a88, fe2b467a, feffd888, fe2cb9d0)
08026a78 libstdc++.so.6.0.3`_ZN10__cxxabiv112__unexpectedEPFvvE(1, fe2cb9d0, 8026af8, fe2b52d6, fe2b53ac, fe217a44)
08026a88 libstdc++.so.6.0.3`_ZN10__cxxabiv112__unexpectedEPFvvE+0x14(fe2b53ac, fe217a44, feffa320, 0, 8026ad8, fe2b7298)
08026af8 libstdc++.so.6.0.3`__cxa_call_unexpected+0x42(8ea9f80, 8026b40, 8c70120, 82aa448, 8e382a8, 8026b20)
08026c68 _ZN21PDRFileTimeoutHandler5checkEv+0xa10(fe17f000, fdfa2a00, 8026c90, fe0a5bf6, fe180680, 0)
08026dec main+0x1309(2, 8026e10, 8026e24)
08026e04 _start+0x80(4, 8027618, 8027682, 802764c, 8027640, 0)
> $G
C++ symbol demangling enabled
> ::quit
Can anyone help me in understanding this output?
Please note that the code has been written in the pmr_colld_aos in directory - /opt/ericsson/aos/PDM/bin/pmr_colld_aos.
Also, I just want to know how to understand such outputs which will help me in backtracing the code.
What you got there is the backtrace of the crash. The last routine that's part of the program was FileTimeoutHandler5checkEv() so it's likely that the error is in there. Everything after this point is part of the C++ library.
But if you really want to examine it, then you should load the core file into GDB along with the program that caused it. It's way easier than examining the core file with mdb.
I used LLVM already existent passes with no problems till I tried to use MemDepPrinter.cpp : http://llvm.org/doxygen/MemDepPrinter_8cpp_source.html . I got the following segfault:
llvm[0]: Compiling MyMemDepPrinter.cpp for Release+Asserts build (PIC)
llvm[0]: Linking Release+Asserts Loadable Module MyMemDepPrinter.so
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.
0 opt 0x08eaf9a8
1 opt 0x08eaff24
2 0xb7753400 __kernel_sigreturn + 0
3 opt 0x08c00c19 llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(llvm::PHITransAddr const&, llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, llvm::SmallVectorImpl<llvm::NonLocalDepResult>&, llvm::DenseMap<llvm::BasicBlock*, llvm::Value*, llvm::DenseMapInfo<llvm::BasicBlock*> >&, bool) + 3673
4 opt 0x08c019aa llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, llvm::SmallVectorImpl<llvm::NonLocalDepResult>&) + 266
5 opt 0x08bf1bed
6 opt 0x08e3415c llvm::FPPassManager::runOnFunction(llvm::Function&) + 636
7 opt 0x08e341c8 llvm::FPPassManager::runOnModule(llvm::Module&) + 56
8 opt 0x08e33de4 llvm::MPPassManager::runOnModule(llvm::Module&) + 692
9 opt 0x08e37270 llvm::PassManagerImpl::run(llvm::Module&) + 240
10 opt 0x08e37386 llvm::PassManager::run(llvm::Module&) + 38
11 opt 0x081a290f main + 6095
12 libc.so.6 0xb74604d3 __libc_start_main + 243
13 opt 0x081b8509
Stack dump:
0. Program arguments: //home/alex/llvm/Release+Asserts/bin/opt -load //home/alex/llvm/Release+Asserts/lib/MyMemDepPrinter.so -memdep -print-memdeps //home/alex/llvm/tools/clang/woRKSPACE/Test.bc
1. Running pass 'Function Pass Manager' on module '//home/alex/llvm/tools/clang/woRKSPACE/Test.bc'.
2. Running pass 'Print MemDeps of function' on function '#_Z9deadcode1i'
./run.sh: line 14: 3326 Segmentation fault (core dumped) //home/alex/llvm/Release+Asserts/bin/opt -load //home/alex/llvm/Release+Asserts/lib/MyMemDepPrinter.so -print-memdeps //home/alex/llvm/tools/clang/woRKSPACE/Test.bc
When I am running it in GDB mode, I get:
Program received signal SIGSEGV, Segmentation fault.
0x08c00c19 in llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(llvm::PHITransAddr const&, llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*, llvm::SmallVectorImpl<llvm::NonLocalDepResult>&, llvm::DenseMap<llvm::BasicBlock*, llvm::Value*, llvm::DenseMapInfo<llvm::BasicBlock*> >&, bool) ()
(gdb) x/i $pc
=> 0x8c00c19 <_ZN4llvm24MemoryDependenceAnalysis27getNonLocalPointerDepFromBBERKNS_12PHITransAddrERKNS_13AliasAnalysis8LocationEbPNS_10BasicBlockERNS_15SmallVectorImplINS_17NonLocalDepResultEEERNS_8DenseMapIS9_PNS_5ValueENS_12DenseMapInfoIS9_EEEEb+3673>: mov 0x10(%eax),%eax
As an update, the line problem is :
MDA.getNonLocalPointerDependency(Loc, true, LI->getParent(), NLDI);
and not the 4 arguments are the problem. All of them are defined and I can use them. I don't have the segfault if I eliminate the line.
I think the problem is defined in a comment :
FIXME: Handle atomic/volatile loads.
Please tell me how can I solve the problem (maybe put a condition to avoid atomic/volatile loads) or if the pass works fine for you and if so, how you use it.
Thank you !
I saw another more recent posts, so i think i is better to try the manual dependencies. It is not the first time then there are errors in open source code. I tried to run the pass and I have the same problem. The same problem with getNonLocalPointerDependency method appears also for the other instruction types, like store, not only in the place mentioned by you.