User forums > Using Code::Blocks

Breakpoints Not Breaking on Flow Control or Assignment Statements

<< < (2/2)

Thoth:
Hello Tim,

Thank you for answering.

The build log is very long.

I have filtered the log to a single component. A pastebin of the distilled items is at: https://pastebin.com/FcMWZRJE


The compilation options are:

--- Code: ---COLLECT_GCC_OPTIONS='-Wall' '-std=c++11' '-fPIC' '-fexceptions' '-v'
'-m64' '-Og' '-g' '-I' '/Libs' '-I' '/Libs/Debian_x64_Debug_Static_GNU/'
'-I' '/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Libs' '-I'
'/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks//../../LPOThirdParty/Source' '-I' '/Libraries/FTDI1/' '-I' '/Libraries/SQLite3/' '-I' '/Libraries/USB1/' '-I' '/usr/include/' '-c' '-o' '/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Out/Debian_x64_Debug_Static_GNU/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Out/Debian_x64_Debug_Static_GNU/CodeTemp/ins_LPOCode/LPO/Source/'

--- End code ---

The linker options are:

--- Code: ---as -v -I /Libs -I /Libs/Debian_x64_Debug_Static_GNU/ -I
/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Libs -I
/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks//../../LPOThirdParty/Source
-I /Libraries/FTDI1/ -I /Libraries/SQLite3/ -I /Libraries/USB1/ -I
/usr/include/ --gdwarf-5 --64 -o
/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Out/Debian_x64_Debug_Static_GNU/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.o /tmp/ccd1ayCl.s
GNU assembler version 2.40 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.40
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../:/lib/:/usr/lib/

--- End code ---

As a reminder, I set break points at lines with 'BP' and the debugger halts at '--->'

--- Code: ---
BP ResultVector[2] = ((DevicesVector.size() >> 8) & 0xFF);
ResultVector[3] = (DevicesVector.size() & 0xFF);

/// Add the Devices Vector to the Command Result Vector.
ResultVector.insert(ResultVector.end(), DevicesVector.begin(), DevicesVector.end());
---> DevicesVector.clear(); std::vector<uint8_t>().swap(DevicesVector);


--- End code ---



=thoth=

ollydbg:
Can you show use the "debugger plugin's debug log" when you start debugging?

It is in the "Debugger" panel, you also need to enable the "debugger plugin's debug log" in the Debugger plugin's setting dialog->"Full (Debug) log" option.

Is that also happens when you debug the code without C::B? I mean in the command line shell(bash)?

Thoth:
Hello ollydbg,

In dealing with the debugger, I learned something new.
Thanks!

I put the full debug log at https://pastebin.com/7S6jSzZR with superfluous information removed.

I have attached an image of this post showing a breakpoint at line 577 and the debugger stopping at line 583.

A relavant line from the debugger line is:

--- Code: ---[debug]> break "/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:577"
[debug]Breakpoint 2 at 0xd9a4: file /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp, line 583.

--- End code ---
I do not know why Breakpoint 2 is created at line 583.

The breakpoint is skipped when I perform the process manually

--- Code: ---/usr/bin/gdb -nx -fullname -quiet  -args /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d
Reading symbols from /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d...
(gdb) set confirm off
(gdb) set args scan blerg probe -JDN 2459034.79167 -Lat 37.3688 Long=-122.0363 -Unk0 Val0 -Fucked= -f= Switch1 Switch2    Switch3  -dead=beef -Switch4 -Switch5
(gdb) break "/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:577"
Breakpoint 1 at 0xd9a4: file /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp, line 583.
(gdb) run
Starting program: /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d scan blerg probe -JDN 2459034.79167 -Lat 37.3688 Long=-122.0363 -Unk0 Val0 -Fucked= -f= Switch1 Switch2    Switch3  -dead=beef -Switch4 -Switch5
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

... program output ...

[Thread 0x7ffff7a1e6c0 (LWP 158065) exited]

Thread 1 "lpo_d" hit Breakpoint 1, LPOProgram::DoCommandScan ( ... )
    at /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:583
��/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:583:14685:beg:0x5555555619a4
(gdb) q


--- End code ---
I expected the debugger to break at line 577.

I am able to replicate the behavior throughout the program being debugged.
I see the behavior with assignment and flow control statements.


=thoth=

Miguel Gimenez:
My opinion is that lines 577 to 582 have been optimized out, but the log data in pastebin is not available:

--- Quote ---Error, this is a private paste or is pending moderation
--- End quote ---

You can add it here as a zip file.

Navigation

[0] Message Index

[*] Previous page