Debugger finished with status 1

[cooboo]

Whenever I try to open the cpu registers window, the window opens for a second, empty, then closes and debugger ends with the code finished with status one. The debugger log shows the cpu registers at least.

The same thing happens if I type info reg into the debugger. Similar thing happens if I type info frame into the debugger (only without being displayed the register info of course).

What does this? This is a bug right?

[BlueHazzard]

Operating system?
Codeblocks version?
Debugger Version?
Can you enable full debugger logging and post the log here?
Settings->Debugger->Common->Full (Debug) Log

[cooboo]

Windows 10

codeblocks 20.03 (I got the self extracting setup that is bundled with mingw)

GDB 8.1

Log is below:



Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\Users\Admin\Desktop\Coding\C\test\test\
Adding source dir: C:\Users\Admin\Desktop\Coding\C\test\test\
Adding file: C:\Users\Admin\Desktop\Coding\C\test\test\bin\Debug\test.exe
Changing directory to: C:/Users/Admin/Desktop/Coding/C/test/test/.
Set variable: PATH=.;C:\Program Files\CodeBlocks\MinGW\bin;C:\Program Files\CodeBlocks\MinGW;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\ImageMagick-7.0.8-Q16;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Users\Admin\AppData\Local\Microsoft\WindowsApps;C:\Users\Admin\AppData\Local\Programs\Python\Python37\Scripts

[debug]Command-line: C:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet  -args C:/Users/Admin/Desktop/Coding/C/test/test/bin/Debug/test.exe
[debug]Working dir : C:\Users\Admin\Desktop\Coding\C\test\test

Starting debugger: C:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet  -args C:/Users/Admin/Desktop/Coding/C/test/test/bin/Debug/test.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Setting breakpoints

[debug]Reading symbols from C:/Users/Admin/Desktop/Coding/C/test/test/bin/Debug/test.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 8.1
[debug]Copyright (C) 2018 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "x86_64-w64-mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 8.1

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 200
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/Admin/Desktop/Coding/C/test/test/
[debug]Source directories searched: C:/Users/Admin/Desktop/Coding/C/test/test;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/Admin/Desktop/Coding/C/test/test/test.c:3"
[debug]Breakpoint 1 at 0x40155b: file C:\Users\Admin\Desktop\Coding\C\test\test\test.c, line 3.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: C:\Users\Admin\Desktop\Coding\C\test\test\bin\Debug\test.exe

Child process PID: 6688

[debug][New Thread 6688.0x6d0]
[debug][New Thread 6688.0x1b5c]
[debug]Thread 1 hit Breakpoint 1, read_req () at C:\Users\Admin\Desktop\Coding\C\test\test\test.c:14
[debug]C:\Users\Admin\Desktop\Coding\C\test\test\test.c:14:196:beg:0x40155b
[debug]>>>>>>cb_gdb:

At C:\Users\Admin\Desktop\Coding\C\test\test\test.c:14

[debug]> if 1
disassemble 0x40155b
info frame
end

[debug] >
[debug] > >Dump of assembler code for function read_req:
[debug]   0x0000000000401550 <+0>:   push   rbp
[debug]   0x0000000000401551 <+1>:   mov    rbp,rsp
[debug]   0x0000000000401554 <+4>:   sub    rsp,0xb0
[debug]=> 0x000000000040155b <+11>:   lea    rcx,[rip+0x2a9e]        # 0x404000
[debug]   0x0000000000401562 <+18>:   call   0x402ab0 <printf>
[debug]   0x0000000000401567 <+23>:   lea    rax,[rbp-0x90]
[debug]   0x000000000040156e <+30>:   mov    rcx,rax
[debug]   0x0000000000401571 <+33>:   call   0x402ac8 <gets>
[debug]   0x0000000000401576 <+38>:   lea    rax,[rbp-0x90]
[debug]   0x000000000040157d <+45>:   mov    rcx,rax
[debug]   0x0000000000401580 <+48>:   call   0x402af8 <atoi>
[debug]   0x0000000000401585 <+53>:   mov    DWORD PTR [rbp-0x4],eax
[debug]   0x0000000000401588 <+56>:   mov    eax,DWORD PTR [rbp-0x4]
[debug]   0x000000000040158b <+59>:   add    rsp,0xb0
[debug]   0x0000000000401592 <+66>:   pop    rbp
[debug]   0x0000000000401593 <+67>:   ret   
[debug]End of assembler dump.

Debugger finished with status 1

[oBFusCATed]

gdb seems to be crashing
Can you reproduce the problem in a command line window outside of codeblocks?

[cooboo]

I'm far from an expert on this, could you give me some guidance as to how I would do this same debugging via command prompt? I can open GDB.exe but I'm not really sure how to proceed..

edit: ok so I opened gdb via C:\Program Files\CodeBlocks\MinGW\bin and got a command prompt, the changed directories to where my test project was, set the breakpoint, ran the program and all good so far, then hit info reg and it momentarily listed the reg info before closing the prompt.

I assume this is what you meant to try? It seems to suffer the same problem.

[BlueHazzard]

i see gdb crashing a lot lately...

Code

info frame 

crashes my debugger on windows (mingw64)

[cooboo]

Well at least It's not just be being daft I guess

Seems to crash in command prompt too.

maybe I should try an older version or something.

[BlueHazzard]

Probably it is this bug...
https://sourceware.org/bugzilla/show_bug.cgi?id=23472

i have gdb 8.1 and this seems to be fixed in 8.2
lets look if i can find 8.2 to confirm

[cooboo]

I'm probably going to sound like a total newbie because I am, but how would I go about updating the gdb my codeblocks uses? it all self installed via a bundled setup file for me.

Im assuming its not as simple as replacing the gdb.exe in  C:\Program Files\CodeBlocks\MinGW\bin with a different gdb.exe

[BlueHazzard]

Ok, i can confirm. With gdb 8.3 everything works...
I use the gdb from msys2 package...

I'm probably going to sound like a total newbie because I am, but how would I go about updating the gdb my codeblocks uses? it all self installed via a bundled setup file for me.

You download the compiler and gdb you want and set up codeblocks paths...

for example if you want to use msys2 (cool because it has a package manager):
!WARNING! This will overwrite your compiler settings, and you will have to recompile everything you want to use in codeblocks
(sadly satha has not updated his wiki page ;( https://github.com/stahta01/MSys2_CodeBlocks_Projects/wiki/Setup-CodeBlocks-to-use-MSys2-MinGW-GCC )
1) Download msys2 and install it
2) Install the mingw compiler with pacman (as described by the link above)
3) Install gdb with pachman (google for it, you will need pacman later )
4) Point the codeblocks compiler to it:
4.1) Settings->Compiler->Select "GNU GCC" from the drop down->Toolchain executables->Compilers installation directory
for me this is

Code

C:\msys64\mingw64\bin

4.2) The Program files should be somehting like this:

Code

C-Compiler: x86_64-w64-mingw32-gcc.exe
C++ Compiler: x86_64-w64-mingw32-g++.exe
...

This files should be found int the top given folder

Code

C:\msys64\mingw64\bin

4.3) Hit ok
5) Setup the debugger
5.1) Settings -> Debugger->Default->Executable path->

Code

C:\msys64\mingw64\bin\gdb

6) Rebuild everything
7) Have fun

[BlueHazzard]

Im assuming its not as simple as replacing the gdb.exe in  C:\Program Files\CodeBlocks\MinGW\bin with a different gdb.exe

If you find the right gdb for this compiler (a newer gdb with an old compiler should always work) but you have to find the right compiler
msys2 compiler will not work with mingw gdb or mingw64 gdb or mingw-tdm gdb

So you have to find the right gdb for your compiler distribution

[cooboo]

Replaced gdb.exe with one I found on a mingw 17.1 installation folder I found and it works now. Nice happy faces.

Too bad I'm too exhausted to code now.

Thank you for all your help!

[oBFusCATed]

BlueHazzard: Can you try the gdb in the latest mingw64 release? A suppose there is newer version that the one we currently ship.

[cooboo]

I think thats what I have done and its working. I'm now using the gdb that comes from here: https://nuwen.net/mingw.html#install

its gdb 8.3.1

[ZLP]

The solution: 
1. Cancel all breakpoints; 
2. Restart debugging. Debug -> Start/Continue; 
3. In the debug window, deselect CPU register in Debug Options and go to Debug -> Debug Window -> Deselect CPU register. 
4. Disable debugging. 
5. Then reset the breakpoint, and the debugging will not flash back; 
6. If you open the CPU register again, the CPU will blink back. Go to Step 1.

The ABOVE METHOD IS ONLY APPLICABLE TO THE case when the CPU register is turned on during breakpoint debugging. Other problems can also be tried using the above method.
I have no idea what this is about, but I found this method by accidentally restarting Codeblocks and debugging it directly. Does this mean that breakpoint debugging cannot open certain info Windows?  Why is that?