How to handle Access violations.

Started by
13 comments, last by Enerjak 16 years, 2 months ago
I seem to be getting alot of access violations when i program. I don't know why. like the code compiles fine but when it's ran, it like gets access violation like before i was trying to make a class to load a model and position in in the world but i got access violations. So what should I keep track ofr when dealing with Access Violations? like what does it mean when it says "Expression cannoit be evaluated" I know what it means in ENGLISH but other wise it just makes no sense since i see that my code is fine and that it compiles fine. Any thoughts?
Advertisement
Quote:Original post by Enerjak
I seem to be getting alot of access violations when i program. I don't know why. like the code compiles fine but when it's ran, it like gets access violation like before i was trying to make a class to load a model and position in in the world but i got access violations. So what should I keep track ofr when dealing with Access Violations? like what does it mean when it says "Expression cannoit be evaluated" I know what it means in ENGLISH but other wise it just makes no sense since i see that my code is fine and that it compiles fine. Any thoughts?
Can you post some of the code that seems to be causing the problems? (Be sure to use [source] tags...)
In the past, I've found the best way to get rid of these kinds of problems is to install an exception handler, and tell the OS to continue execution.

If you're developing in a Windows based environment, the following code can accomplish this...

At the top of your source file containing WinMain, add the function definition:
LONG WINAPI IgnoreAccessViolations (struct _EXCEPTION_POINTERS* exception_info){    /* ignore access violations, and continue executing */    return EXCEPTION_CONTINUE_EXECUTION;}


At the start of your WinMain function, add the following function call:
SetUnhandledExceptionFilter(&IgnoreAccessViolations);


Access violations shouldn't get in your way any more.

--Andrew
Given your past experience, I would recommend minimally trying to read the documentation for the functions you use and check return values as well as parameters to see if they are valid.
Quote:Original post by agottem
In the past, I've found the best way to get rid of these kinds of problems is to install an exception handler, and tell the OS to continue execution.

That is quite possibly the worst advice I've ever read on these forums. And I've seen a lot of bad advice here.
Quote:Original post by agottem
In the past, I've found the best way to get rid of these kinds of problems is to install an exception handler, and tell the OS to continue execution.

If you're developing in a Windows based environment, the following code can accomplish this...

At the top of your source file containing WinMain, add the function definition:
*** Source Snippet Removed ***

At the start of your WinMain function, add the following function call:
*** Source Snippet Removed ***

Access violations shouldn't get in your way any more.

--Andrew

Wow, that's possibly the worst piece of advice I've ever seen. Well done.

Access violations mean your code did something wrong - usually you tried to access a null pointer, or access memory you didn't allocate. Ignoring the problem by sticking your head in the sand and attempting to carry on like nothing happened is not the way to solve it. You need to figure out exactly what is going wrong and fix it properly.

Enerjak: Post code, preferably something complete but minimal. Also try running your code in your debugger and see what happens when it crashes - it should point you to where the code is actually going wrong.
Quote:Original post by agottem
In the past, I've found the best way to get rid of these kinds of problems is to install an exception handler, and tell the OS to continue execution.

If you're developing in a Windows based environment, the following code can accomplish this...

At the top of your source file containing WinMain, add the function definition:
*** Source Snippet Removed ***

At the start of your WinMain function, add the following function call:
*** Source Snippet Removed ***

Access violations shouldn't get in your way any more.

--Andrew

I LOL'd.
Another simple answer is: "learn to use the debugger". An access violation will break into the debugger; from there you can examine your variable values and diagnose exactly what went wrong and why.

An Access Violation is a bug in _your_ code that _you_ need to fix. It's not someone else's problem for you to hide or ignore.

-me
Ok, i'll post the code and also a picture of the debugger. the thning is, i use the debugger but the numbers just don't make sense. here is the code.

int MODEL::LoadModel(char *filename){     LPD3DXBUFFER matbuffer;    HRESULT result;    //load mesh from the specified file    result = D3DXLoadMeshFromX(        filename,               //filename        D3DXMESH_SYSTEMMEM,     //mesh options        d3ddev,                 //Direct3D device        NULL,                   //adjacency buffer        &matbuffer,             //material buffer        NULL,                   //special effects		&material_count, //number of materials		&mesh);          //resulting mesh    if (result != D3D_OK)    {        MessageBox(NULL, "Error loading model file", "Error", MB_OK);        return NULL;    }    //extract material properties and texture names from material buffer    LPD3DXMATERIAL d3dxMaterials = (LPD3DXMATERIAL)matbuffer->GetBufferPointer();    materials = new D3DMATERIAL9[material_count];    textures  = new LPDIRECT3DTEXTURE9[material_count];    //create the materials and textures    for(DWORD i=0; i<material_count; i++)    {        //grab the material       materials = d3dxMaterials.MatD3D;        //set ambient color for material         materials.Ambient = materials.Diffuse;       textures = NULL;        if( d3dxMaterials.pTextureFilename != NULL &&             lstrlen(d3dxMaterials.pTextureFilename) > 0 )        {            //load texture file specified in .x file            result = D3DXCreateTextureFromFile(d3ddev,                 d3dxMaterials.pTextureFilename,                 &textures);            if (result != D3D_OK)            {                MessageBox(NULL, "Could not find texture file", "Error", MB_OK);                return NULL;            }        }    }    //done using material buffer    matbuffer->Release();    return 1;}void MODEL::DeleteModel(){    //remove materials from memory    if( materials != NULL )         delete[] materials;    //remove textures from memory    if (textures != NULL)    {        for( DWORD i = 0; i < material_count; i++)        {            if (textures != NULL)                textures->Release();        }        delete[] textures;    }        //remove mesh from memory    if (mesh != NULL)        mesh->Release();  }void MODEL::DrawModel(){    //draw each mesh subset    for( DWORD i=0; i<material_count; i++ )    {        // Set the material and texture for this subset        d3ddev->SetMaterial( &materials );        d3ddev->SetTexture( 0, textures );            // Draw the mesh subset        mesh->DrawSubset( i );    }}int MODEL::PositionModel(int x, int y, int z){		X = x;	Y = y;	Z = z;	D3DXVECTOR3 Vec((float)X,(float)Y,(float)Z);	D3DXMatrixTranslation(&MatTrans,x,y,z);	d3ddev->SetTransform(D3DTS_WORLD,&MatTrans);	return 1;}


it points to "i" as an access violation then there's a "this" violation that is saying that the MatTrans can't be evaluted, and it's saying that all the opther variables can't be evalueted.

here is my model class

class MODEL{public:	int LoadModel(char *);	VOID DeleteModel();	void DrawModel();	int  PositionModel(int x, int y, int z);private:	D3DXMATRIX MatTrans;	int X;	int Y;	int Z;    LPD3DXMESH mesh;    D3DMATERIAL9* materials;    LPDIRECT3DTEXTURE9* textures;    DWORD material_count;};it's saying all the private members can't be evalueted. so, i hope you can help me. also, it points to line 316 + 0x18 bytes.EDIT: I seem to have fixed the problem by called MODEL* box = new MODEL()Ok, i seem to have fixed it, so when dealing with classes i should ALWAYS allocate it with the new keyword? 
Quote:Original post by agottem
In the past, I've found the best way to get rid of these kinds of problems is to install an exception handler, and tell the OS to continue execution.

If you're developing in a Windows based environment, the following code can accomplish this...

At the top of your source file containing WinMain, add the function definition:
*** Source Snippet Removed ***

At the start of your WinMain function, add the following function call:
*** Source Snippet Removed ***

Access violations shouldn't get in your way any more.

--Andrew


Holy Bad Advice, Batman! (NEVER do this)

Adding exception handlers in general should really only be used when you want to make some sort of debug output when the exception happens... For example, dumping the call stack once an exception occcurs is an excellent way to trace the problem (especially if you've released this program already and are getting bug reports from users)

This topic is closed to new replies.

Advertisement