• 15
• 15
• 11
• 9
• 10

# How does one usually fix segmenation errors?

This topic is 4862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I've been plagued by them many times while making games, and I'm thinking it's more involving defining class functions and not in including multiple files in a project considering I've tried putting everything into one file. I've damn near been driven to game-makers because of this problem. I don't have the code with me (I'm typing his during a lecture at school), but any general advice would be very much appreciated :)

##### Share on other sites
Segmentation faults are generally caused by writing past the bounds of allocated memory. In other words, you are trying to index an array or some other container with an index that is out of bounds.

##### Share on other sites
Is going

class Class{
void function();
};

void Class::function(){
/* BLAH BLAH BLAH */
}

the cause of it? I don't quite think so, but it's the only idea I've got--even if it doesn't make much sense looking at other programs where it runs fine.

##### Share on other sites
A segfault is simply the result of attempting to access memory you do not have access to. This is typically the result of dereferencing either a null pointer, an uninitialised pointer, or a pointer whose pointed-to memory has been freed, or accessing data beyond the bounds of a container. Backtrace, backtrace, backtrace ...

##### Share on other sites
no that's definitely not the problem. like the previous poster suggested you are most likely writing past the bounds of an array. for instance the following could cause a seg fault:

char foo[10];strcpy( foo, "I am crashing now\n" );//crash b/c the foo array isn't big enough to hold the whole stringchar *poo;strcpy( poo, "I will crash also\n");//crash b/c the char* poo has not been allocated

the only good way to find a seg fault is to run your program through a debugger and step through the code till it faults. alternitively you can put in some printf's throughout your program and narrow in on the line that crashes.

-me

##### Share on other sites
Quote:
 Original post by Palidinethe only good way to find a seg fault is to run your program through a debugger and step through the code till it faults. alternitively you can put in some printf's throughout your program and narrow in on the line that crashes.

I still say a backtrace (which I cannot imagine a decent debugger would lack) is a much faster solution, narrowing it down to at least function level without the hassle of having to step through a potentially long run.

##### Share on other sites
Unfortunately, Dev-C++'s debugger isn't working right for me. I think the making arrays out of the objects in setup() is what's over-stepping the boundaries.

#include <stdlib.h>

#include <SDL/SDL.h>

enum COLOR { VOID, RED, BLU, GRE, YEL, PUR };
enum DIR { HORI, VERT };

struct CSprite
{
SDL_Surface *image;
COLOR color;
int mX, mY;
int ID;
int cPos, rPos;
};

struct coordinate
{
int x, y;
bool occupied;
int ID;
COLOR color;
bool tagged;
};

class CField
{
public:
void setup();

void draw(CSprite&);
void move(CSprite&, int, DIR);

void drawField(SDL_Surface*);
void drawBlocks();
void drawCursor();
void drawSection();

void setBlock(int, COLOR, int, int);
void setCursor(int, int);
inline void updateObj(CSprite&);

void swapBlock();
void popBlock(int);

void collapseBlock(int, int);
void collapseBlocks();

void sweepField();

private:
CSprite *cursor;
CSprite *block;

SDL_Surface *field;
SDL_Surface *redBlock, *greBlock, *bluBlock,
*yelBlock, *purBlock;

coordinate **grid;
};

void CField::setup()
{
grid = new coordinate*[5];
for( int j; j<6; j++ ) grid[j] = new coordinate[7];

for( int COL=0; COL<5; COL++ ) {
for( int ROW=0; ROW<7; ROW++ ) {
grid[COL][ROW].x = COL * 4/*NOT FINAL*/;
grid[COL][ROW].y = ROW * 4/*NOT FINAL*/;
}}

block = new CSprite[48];
for(int ID=0; ID<48; ID++) block[ID].ID = ID;