Codeblocks 32 bit 20.03 with mingw is broken. Doesn't find compiler and debugger

[hidrerarta]

I installed 64 bit code blocks 20.03 with mingw. I tried to compile 32 bit application with -m32 flag but it doesn't work because there are no 32 bit libraries.
https://forums.codeblocks.org/index.php?topic=23868.0

Because of that I downloaded 32 bit code blocks 20.03 with mingw. After installation and running it, it showed error that there is no compiler executable. I had to fix path to compiler and file names. After that it worked and I compiled my 32 bit application.
When I run my application it crashes at some point. I wanted to find out why so I compiled debug version with debugging symbols and I run it with debugger. However, when the application crashes the debugger doesn't show line of code that makes it crash, debugger is broken.

Then I installed codeblocks 17.02 32 bit. When I try to debug there is error that debugger cannot be found. After I set it to C:\Program Files (x86)\CodeBlocks\MinGW\bin\gdb32.exe when I try to debug, I get "Debugger finished with status 1" when trying to debug my application.

What to do now when no codeblocks version works? I will look for alternatives.
https://alternativeto.net/software/codeblocks/

[hidrerarta]

Maybe I should install 64 bit 20.03 again, but add 32 bit mingw compiler to it? But I don't know how.

[Grit Clef]

Simply Install CodeBlocks 64 bit, and download a 32 bit gcc, you can get it run. Some sources that you can download gcc-on-Windows packages from can be such as https://www.winlibs.com/, then set it in your 64 bit CodeBlocks compiler Settings.

[hidrerarta]

Simply Install CodeBlocks 64 bit, and download a 32 bit gcc, you can get it run. Some sources that you can download gcc-on-Windows packages from can be such as https://www.winlibs.com/, then set it in your 64 bit CodeBlocks compiler Settings.

I installed codeblocks 20.03 64-bit.
I downloaded this:
GCC 13.2.0 (with POSIX threads) + LLVM/Clang/LLD/LLDB 17.0.6 + MinGW-w64 11.0.1 (MSVCRT) - release 5   (LATEST)

Unpacked it and set in Codeblocks to use this compiler.
I also set debugger to this GCC 13.2.0 that I downloaded.

When I compile my program it compiles. I rebuild it. When I try to debug it, the debugger doesn't work because it doesn't show line of code where my application crashes. I compiled debug version with debugging symbols. But debugger doesn't work.
Also when I click "Break debugger" before my application crashes, nothing happens.

Trying to interrupt process with pid: 3216; child pid: 3216 gdb pid: 10872
In ?? () ()

[hidrerarta]

[debug]Thread 25 received signal SIGSEGV, Segmentation fault.
[debug][Switching to Thread 7332.0x2b84]
[debug]0x011df854 in ?? ()
[debug]>>>>>>cb_gdb:

In ?? () ()

[debug]> bt 30
[debug]#0  0x011df854 in ?? ()
[debug]Backtrace stopped: Cannot access memory at address 0x443ec004
[debug]>>>>>>cb_gdb:

Debugger finished with status 0

[hidrerarta]

I have spaces in my project directory.

[hidrerarta]

I tried older version
GCC 9.5.0 + MinGW-w64 10.0.0 (MSVCRT) - release 1

But same bug.

[hidrerarta]

I installed codeblocks competition called CodeLite. But it's even worse than codeblocks, it doesn't compile when there are spaces in path.
https://github.com/eranif/codelite/issues/1845

[hidrerarta]

I tried GCC 7.5.0 + MinGW-w64 7.0.0 (MSVCRT) - release 1

Debugger doesn't work.

[sodev]

I don't know why you think you can solve your problem by downgrading even further. Especially for such a well known, longstanding problem, like spaces in paths.

But you already named the issue, spaces in path, and there is a simple solution for this: remove the spaces.

[hidrerarta]

I don't know why you think you can solve your problem by downgrading even further. Especially for such a well known, longstanding problem, like spaces in paths.

But you already named the issue, spaces in path, and there is a simple solution for this: remove the spaces.

It's not because of spaces. I copied the project to path without spaces, opened it and started debugger. Same problem. Debugger runs but doesn't work correctly, doesn't display line of code.

[hidrerarta]

I have 64 bit operating system, 64 bit codeblocks, 32 bit MINGW. If that matters. I tried both 32 bit GDB and 64 bit. Same result.

[hidrerarta]

When I debug my application, when I set breakpoints they work. But when my application crashes it doesn't show on what line of code.

[hidrerarta]

My application crashes when there is a lot of graphics data displayed with opengl. When I stop displaying text it doesn't crash. But debugger doesn't show any information where it crashes.

[sodev]

I am not an expert of GDB but if the crash does happen inside an external library you need the debugging symbols of that library as well. But even without you should get a backtrace of at least the path inside your application.

[ollydbg]

I have 64 bit operating system, 64 bit codeblocks, 32 bit MINGW. If that matters. I tried both 32 bit GDB and 64 bit. Same result.

I think if you want to build 32bit applications under windows, you need a 32bit C::B, 32bit gcc compiler suite, and 32bit gdb.

If you want to build 64bit applications, then all the tools should be 64bit.

The internal reason is that if you want to halt the debugee when debugging, you need to call an Win32 API function from C::B, and the debugger have to catch the exception. All the process should be in same 64bit application processes or 32 bit processes.

[nenin]

My application crashes when there is a lot of graphics data displayed with opengl. When I stop displaying text it doesn't crash. But debugger doesn't show any information where it crashes.

1. If you want to debug 32b code using 64b C::B you have to use fresh 64b gdb. gcc version may be different, however better dont go below 9. Sometimes it require some efforts to enforce C::B to choose gdb you want to use.
2. If you need to catch something really bad, you can link your soft with drmingw dlls, https://github.com/jrfonseca/drmingw - in this case it will generate *.rpt file on run time error. In this file for code with debug info you can find source of the error. You also can install drmingw as system debugger, however I dont know how it works in case of 32b on 64b Win. I prefer to link dlls.