llvm MemDepPrinter segfault - llvm

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.

Related

gdb stops at breakpoint, but no code is shown

I've recently changed compilers from the Oracle Studio compiler on RHEL7 to Clang on RHEL8 due to no support of the oracle compiler. I'm trying to debug our application using GDB, but running into some issues I am yet to find a solution for.
I can set a breakpoing with:
b class::function or
b file.cc:linenumber
It does break when it hits that breakpoint, but no code is shown at that location. Funnily enough, some stuff does, and in this case, it shows line numbers in the base class.
this is the stack on break:
Thread 41 "dms" hit Breakpoint 2, 0x0000000000880f44 in
User_Registrar::login(Address const*, int, char const*, Boolean,
RWCString) ()
(gdb) where
#0 0x0000000000880f44 in User_Registrar::login(Address const*, int,
char const*, Boolean, RWCString) ()
#1 0x0000000000878dfb in
User_Registrar::userLoginRequest(UserLoginRequest*) ()
#2 0x0000000000871597 in User_Registrar::processMessage(Message*) ()
#3 0x00000000009cd530 in MessageHandlerObject::processMessageQueue
(this=0x7fffe8068010) at BaseObjects.cc:488
#4 0x00000000009cd40e in
MessageHandlerObject::processMessageQueueStartup
(thisInstance=0x7fffe8068010) at BaseObjects.cc:447
#5 0x00007ffff69d887c in stl_thread_start_rtn () from
/opt1/dms/lib/libthread.so
#6 0x00007ffff643318a in start_thread () from /lib64/libpthread.so.0
#7 0x00007fffee095dd3 in clone () from /lib64/libc.so.6
(gdb) up
#1 0x0000000000878dfb in
User_Registrar::userLoginRequest(UserLoginRequest*) ()
(gdb) down
#0 0x0000000000880f44 in User_Registrar::login(Address const*, int,
char const*, Boolean, RWCString) ()
(gdb)
Am I missing something like a limit or something similar?
Things I have checked:
Yes, it is being compiled with -g
objdump does show the debug_info for the source file
gdb does show it has loaded the source file
(gdb) where
#0 0x0000000000880f44 in User_Registrar::login(Address const*, int, char const*, Boolean, RWCString) ()
Note that there is no file / line info for this level -- that is the reason GDB doesn't show source.
Why did this happen? Clang omits file/line info under certain conditions when optimization is in effect (as far as I understand, when code is inlined and re-ordered, it is sometimes hard to keep code to file/line association).
If you can disable optimizations, or add __attribute__((noinline)) to the login() function, you'll have a better debugging experience.
If you must debug this particular function with optimizations, you'll have to disassemble it and reconstruct the code to file/line association "by hand".
If gdb doesn't know where to look for the source file, you can use the directory command to add a path: gdb directory command

Weird iOS crash stack without the called function [closed]

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/

STL type/function used in gdb conditional break, will crash the program?

I wish to test in my program below: when s="abc", break inside "f()" and see the value if "i".
#include<string>
using namespace std;
int i=0;
void f(const string& s1)
{
++i; // line 6
}
int main()
{
string s="a";
s+="b";
s+="c";
s+="d";
s+="e";
s+="f";
return 0;
}
Compile and run a.out, no problem. I then debug it
g++ 1.cpp -g
gdb a.out
...
(gdb) b main if strcmp(s.c_str(),"abc")==0
Breakpoint 1 at 0x400979: file 1.cpp, line 9.
(gdb) r
Starting program: /home/dev/a.out
Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory.
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(__strcmp_sse2_unaligned) will be abandoned.
When the function is done executing, GDB will silently stop.
Program received signal SIGSEGV, Segmentation fault.
Breakpoint 1, __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31 in ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S
If I change the break point declaration into:
(gdb) b main:6 if s.compare("abc")==0
Breakpoint 1 at 0x400979: file 1.cpp, line 9.
Then I get another kind of crash, seems:
(gdb) r
Starting program: /home/dev/a.out
Program received signal SIGSEGV, Segmentation fault.
__memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:1024
1024 ../sysdeps/x86_64/multiarch/memcmp-sse4.S: No such file or directory.
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const) will be abandoned.
When the function is done executing, GDB will silently stop.
Program received signal SIGSEGV, Segmentation fault.
Breakpoint 1, __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:1024
1024 in ../sysdeps/x86_64/multiarch/memcmp-sse4.S
Is this crash caused by gdb, or my command? If my command has runtime problem, why gdb doesn't simply report an error, by rather crash the program?
Hope to get some explanations, as I didn't get this error cause.
What is going on here is that your command:
(gdb) break main:6
... is interpreted by gdb as the same as break main. You can see this by typing the latter as well:
(gdb) b main:6
Breakpoint 1 at 0x400919: file q.cc, line 10.
(gdb) b main
Note: breakpoint 1 also set at pc 0x400919.
Breakpoint 2 at 0x400919: file q.cc, line 10.
Now, this is peculiar because gdb presumably ought to warn you that the trailing :6 is ignored. (I'd recommend filing a bug asking that this be made a syntax error.)
If you want to break at a certain line in a file you must use the source file name. Presumably you meant to type:
(gdb) break main.cc:6

Unable to set a breakpoint on main while debugging a program compiled with Rust 1.10 with GDB

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.*'

can print from command line, but cannot get it from the program

I use gdb to debug my program, when I unpack a message and wanna print it, I got a problem. It seems that i can print from command line in the terminal, but when program goes to the printf("%d has received msg: ", msg->connid);, I got the problem,
Program received signal SIGSEGV, Segmentation fault.
0xb7ff6301 in ?? () from /lib/ld-linux.so.2
(gdb)n
154 LSPMessage* msg = lspmessage__unpack(NULL, msg_len, buf);
(gdb) n
156 memcpy(pld, msg->payload.data, msg->payload.len);
(gdb) p msg->payload.data
$1 = (uint8_t *) 0x804c038 "Connectedrt,\031"
(gdb) p msg->connid
$2 = 1
(gdb) p msg->payload.len
$3 = 9
174 printf("%d has received msg: ", msg->connid); // required field
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xb7ff6301 in ?? () from /lib/ld-linux.so.2
You did a remarkably poor job of explaining what it is you are actually asking.
I think your question is: "how come my printf call crashes?".
There could be several reasons
You have corrupted stdout earlier, or
msg->connid is not int (and so it is wrong to printf it with "%d", or
you have corrupted something else in the runtime loader state, and it now crashes while doing lazy PLT symbol resolution
Since you crash is inside the runtime loader, that last cause appears to be most likely. You can confirm this hypothesis by forcing the loader to perform symol resolution non-lazily:
(gdb) set env LD_BIND_NOW 1
(gdb) run
Did it still crash? If not, run your program under Valgrind, and be sure to fix all the problems it reports.