User forums > Help

Gdb shows nothing

<< < (2/3) > >>

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:

--- Quote from: oBFusCATed on September 09, 2017, 06:13:13 pm ---Or if it is somewhere in a module that has not been compiled with mingw.
--- End quote ---

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:

--- Quote from: oBFusCATed on September 10, 2017, 10:21:06 am ---You didn't give me any information about what the problem was.
--- End quote ---

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;
}

--- End code ---

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;

--- End code ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page