Gdb shows nothing

[Krice]

I've build my project with -g and without -s obviously, on Windows 10 / SDL2 project. When I run the program with F8 it does exit on crash, but the debugger tells nothing about it, other than exit code 03. Am I missing something here? In this case I know why and where the crash happens, but shouldn't the debugger know it, too?

[oBFusCATed]

Most probably some dll is not found. GDB is not very good for telling you about these problems.
A better guess could be made if you provide the full debug log (it should be enabled in the settings of the debugger; make sure to use code or quote tags when pasting logs).

[Krice]

Code

[debug]Command-line: C:\TDM-GCC-32\bin\gdb32.exe -nx -fullname -quiet  -args C:/projects/Teemu/Teemu.exe
[debug]Working dir : C:\projects\Teemu

Starting debugger: C:\TDM-GCC-32\bin\gdb32.exe -nx -fullname -quiet  -args C:/projects/Teemu/Teemu.exe
done

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

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from C:/projects/Teemu/Teemu.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.9.1
[debug]Copyright (C) 2015 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 "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) 7.9.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 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Program Files (x86)\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/projects/Teemu/
[debug]Source directories searched: C:/projects/Teemu;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: C:\projects\Teemu\Teemu.exe 

Child process PID: 6644

[debug][New Thread 6644.0x440]
[debug][New Thread 6644.0x2484]
[debug][New Thread 6644.0x1264]
[debug][New Thread 6644.0x1508]
[debug][New Thread 6644.0x1ba0]
[debug][Thread 6644.0x1ba0 exited with code 0]
[debug][New Thread 6644.0x15c8]
[debug][Thread 6644.0x1508 exited with code 3]
[debug][Thread 6644.0x1264 exited with code 3]
[debug][Thread 6644.0x2484 exited with code 3]
[debug][Thread 6644.0x15c8 exited with code 3]
[debug][Inferior 1 (process 6644) exited with code 03]
[debug]>>>>>>cb_gdb:

[Inferior 1 (process 6644) exited with code 03]

[debug]> quit

Debugger finished with status 0

[oBFusCATed]

You can try to put a breakpoint on exit and see what happens.
But I'm not 100% sure that this is the function that is called for all cases when on wants to exit a thread.

To set a breakpoint you need to add "break exit" in the initial commands in the debugger settings.

[Krice]

To set a breakpoint you need to add "break exit" in the initial commands in the debugger settings.

I don't even know what that means. Isn't the idea when a program crashes the debugger can show where it crashed? I'm not proud of this, but I re-installed Visual Studio and debugged exactly the same project. Boom. It found the place where it crashes. I'm just baffled about gdb, what it is actually doing when it doesn't notice the crash. It just exits as if nothing happened.

[oBFusCATed]

And what was the cause of your problem?
If it is some microsoft style exception then gdb won't be able to catch it.
Or if it is somewhere in a module that has not been compiled with mingw.

[Krice]

Or if it is somewhere in a module that has not been compiled with mingw.

It was in the main source code. I've set up my project in a weird way I guess, it can be compiled in CB/gcc or Visual Studio. In this case gcc builds the .exe in root directory and VS makes it in Debug directory. Gdb is running the .exe compiled with gcc so there is not that problem. The only external library I'm using is SDL2. Break points and step into source code works. I feel like I'm missing something here.

[oBFusCATed]

You could have not written this post. You didn't give me any information about what the problem was.
Now I have now idea if I could do something to improve the gdb integration in C::B...

[Krice]

You didn't give me any information about what the problem was.

What does it matter? It could have been anything. But in this case the bug that caused the crash was an init order fiasco. A base class constructor tried to access data that was using a virtual getter from derived class. But since the derived part of the class is not yet constructed it's returning random data. This is exactly where the program crashed:

Code

void Terrain_Tile::Put_Object(Game_Object *o)
{
	//determine in which object slot the object belongs using its type
	const int t=o->Get_Object_Type();
	if (goty::is_mover(t)) mover=o;
	else rooted=o;
}

Terrain_Tile is a tile object of 2D map in a roguelike game. Game_Object is the base class of game objects, but when you call Get_Object_Type using partly constructed class it returned stuff like -458433939 or whatever for 't'. is_mover() then accessed that index and was greatly out-of-bounds. The way I fixed this bug was removing map handling inside Game_Object when creating an object. It's anyway bad practice, because it assumes that the 2D map exists and also there was that virtual getter problem.

[oBFusCATed]

So, you're creating threads before main has started?
Is the problem in a dll?

On linux if I use this code in a simple program:

Code

struct A
{
    A()
    {
        int *a=0;
        *a=5;

        exit(4);
    }
};

A a;

GDB stops correctly at the place of the crash. What happens with your version of GDB if you use this code?

[Krice]

What happens with your version of GDB if you use this code?

It shows where the crash happens. Maybe it doesn't catch everything?

[Krice]

I went back to the project and tried to reproduce the bug by using same kind of init order fiasco, although I had changed the class where the 2D map is set. This time gdb catched the crash, so it does work (usually?). Only thing I have changed was that I removed Visual Studio 2015 and installed VS 2017, but how could it possibly affect to CB and gdb? I don't remember changing any settings for the debugger or compiler in CB.

[oBFusCATed]

Don't you have the broken version in source control? What happens if you try the broken revision?

[Krice]

Don't you have the broken version in source control?

I don't use source control. If the problem returns I'll be back to whine about it. Meanwhile I found out that some virus had taken over MsMpEng.exe and the virus check had not been run for about week. I had to remove that override from the register, because it would be too much to ask Windows Defender to find that stuff by itself. I just love Windows platform and development.

[oBFusCATed]

I don't use source control.

I guess you're doomed.