negative in stop reason

Dear all,

I have just debug KLEE with lldb. A breakpoint was set on the function “executeAllocUnbounded”. After the breakpoint was hiited, I used “continue” to let the program to go on. However, it did not work. The respose from lldb is following:

(lldb)
Process 10254 stopped

  • thread #1, name = ‘klee’, stop reason = breakpoint 3.1 -1364.1
    frame #0: klee`klee::Executor::executeAllocUnbounded(this=0x0000000001278800, state=0x000000000132d710, size=4, target=0x000000000134ef00) at Executor.cpp:3036

NOTE that, there is a negative number “-1364.1” showed in stop reason. When I hit “continue” again, the number was change to “-1366.1”, by mius -2

I want to know what is the mean of “-1364.1” here. How to let the program to continue. Thanks.

Negative breakpoint ID’s are used for breakpoints lldb sets for internal purposes. You can see the internal breakpoints with the “break list -i” command.

“continue” doesn’t usually need to set internal breakpoints, however. And we don’t usually tell you about internal breakpoint hits, especially if you hit a user breakpoint at the same time. So that is a little curious. But I also wonder if you are hitting this breakpoint over and over? What is the hit count on breakpoint 3? You can see this in the output of “break list 3.1"

Jim

Negative breakpoint ID’s are used for breakpoints lldb sets for internal
purposes. You can see the internal breakpoints with the “break list -i”
command.

“continue” doesn’t usually need to set internal breakpoints, however. And
we don’t usually tell you about internal breakpoint hits, especially if you
hit a user breakpoint at the same time. So that is a little curious. But
I also wonder if you are hitting this breakpoint over and over?

Hi Jim, Thanks for your reply. Yes, I have hit the breakpoint over and
over.

I replay the same debugging process again today. This time, the break point
is set as breakpoint 2 (not breakpoint 3 in my early email). When I input
"break list 2.1“, lldb shows:

(lldb) br list 2.1
2: file = 'Executor.cpp', line = 3222, exact_match = 0, locations = 1,
resolved = 1, hit count = 1
  2.1: where =
klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool,
klee::ref<klee::Expr>, klee::ref<klee::Expr>, klee::KInstruction*) + 39 at
Executor.cpp:3228, address = 0x0000000000547807, resolved, hit count = 1

When I use "continue" to let the program to go on, lld shows:

(lldb) br list 2.1
2: file = 'Executor.cpp', line = 3222, exact_match = 0, locations = 1,
resolved = 1, hit count = 1
  2.1: where =
klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool,
klee::ref<klee::Expr>, klee::ref<klee::Expr>, klee::KInstruction*) + 39 at
Executor.cpp:3228, address = 0x0000000000547807, resolved, hit count = 1

(lldb) n
Process 6706 stopped
* thread #1, name = 'klee', stop reason = breakpoint 2.1 -4.1
    frame #0:
klee`klee::Executor::executeMemoryOperation(this=0x0000000001278800,
state=0x000000000132d710, isWrite=true, address=ref<klee::Expr> @
0x00007fffffffd480, value=ref<klee::Expr> @ 0x00007fffffffd4b0,
target=0x0000000000000000) at Executor.cpp:3228
   3225 ref<Expr> value /* undef if
read */,
   3226 KInstruction *target /* undef
if write */) {
   3227 Expr::Width type = (isWrite ? value->getWidth() :
-> 3228 getWidthForLLVMType(target->inst->getType()));
   3229 unsigned bytes = Expr::getMinBytesForWidth(type);
   3230 std::string name = "node";
   3231 if (SimplifySymIndices) {
(lldb)

Obviously, the program do NOT go on. As you said, internal breakpoints were
hit, because of a negative number "-4.1" in stop reason. When I input
"continue" again, it shows.

(lldb) n
Process 6706 stopped
* thread #1, name = 'klee', stop reason = breakpoint 2.1 -6.1
    frame #0:
klee`klee::Executor::executeMemoryOperation(this=0x0000000001278800,
state=0x000000000132d710, isWrite=true, address=ref<klee::Expr> @
0x00007fffffffd480, value=ref<klee::Expr> @ 0x00007fffffffd4b0,
target=0x0000000000000000) at Executor.cpp:3228
   3225 ref<Expr> value /* undef if
read */,
   3226 KInstruction *target /* undef
if write */) {
   3227 Expr::Width type = (isWrite ? value->getWidth() :
-> 3228 getWidthForLLVMType(target->inst->getType()));
   3229 unsigned bytes = Expr::getMinBytesForWidth(type);
   3230 std::string name = "node";
   3231 if (SimplifySymIndices) {

The negative number in stop reason becomes to "-6.1". When I query internal
breakpoints with the “break list -i” command, it shows.

(lldb) break list -i
Current breakpoints:
Kind: shared-library-event
-1: address = klee[0x00000000005361a0], locations = 1 Options: disabled
one-shot

  -1.1: where = klee`_start, address = 0x00000000005361a0, unresolved, hit
count = 1

Kind: shared-library-event
-2: address = ld-linux-x86-64.so.2[0x0000000000011060], locations = 1,
resolved = 1, hit count = 0

  -2.1: where = ld-linux-x86-64.so.2`_dl_debug_state, address =
0x00007ffff7de8060, resolved, hit count = 0

Kind: step-out
-6: address = klee[0x0000000000547807], locations = 1, resolved = 1, hit
count = 1 Options: enabled tid: 0x1a32
  -6.1: where =
klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool,
klee::ref<klee::Expr>, klee::ref<klee::Expr>, klee::KInstruction*) + 39 at
Executor.cpp:3228, address = 0x0000000000547807, resolved, hit count = 1

I can not understand outputs from "break list -i” command. I wonder how to
let the program to go on. BTW, I use lldb-4.0 in Ubuntu 16.04 AMD64.

-Jian

The breakpoint hit count is not increasing, which makes it look like we aren’t managing to do the job of stepping past the breakpoint. That requires restoring the breakpoint instruction, setting the processor to single-step, running just the thread that hit the breakpoint, then reinserting the trap.

I can’t see from the info you gave why this might be happening.

You can get lldb to dump the log of its stepping operations by running the command:

(lldb) log enable -f /tmp/lldb-step-log.txt

then step, then you can look at the log to see what happened. You might find this log confusing if you don’t know how lldb works but if you file a bug with the llvm.org bugreporter (bugs.llvm.org) and include this log, the output you listed below and the disassembly of the function you are trying to step past, I will take a look.

Jim