Access violation reading location 0x00000034.

Started by
14 comments, last by ljerabek 14 years, 10 months ago
"Unhandled exception at 0x0041a024 in Shredding_Legend.exe: 0xC0000005: Access violation reading location 0x00000034." For some reason i receive this error message after running my program, it doesnt even bring up the window or anything, it automatically jumps to this. A few source codes to show:

const_iterator end() const
	{// return iterator for end of nonmutable sequence
		return (const_iterator(_Myhead, this));
	}
List? this is where debugger says the problem is.

//The headers
#include "SDL.h"
#include "SDL_image.h"
#include "SDL_mixer.h"
#include "const.h"
#include "inifile.h"
#include <string>

CIniFile ini;

//Screen attributes
const int SCREEN_WIDTH = atoi( ini.GetSection("Video")->GetKey("Width")->GetValue().c_str() );
const int SCREEN_HEIGHT = atoi( ini.GetSection("Video")->GetKey("Height")->GetValue().c_str() );
const int SCREEN_BPP = 32;

//The frame rate
const int FRAMES_PER_SECOND = 55;
Config.cpp (This is where something is wrong, everything compiles right) i am using Ludvik Jerabek's INI Reader / Writer Class for MFC and ANSI C++(http://www.codeproject.com/KB/cpp/CIniFile.aspx) for the ini loading and stuff. thanks for the help in advanced. Just ask if there s anything that needs to be provided that i didnt.
Advertisement
One of your Get... is almost certainly returning null. Trying to access a member of it offsets it by 0x34 bytes, which is then your error location.
Hey,

do you load any file before you use the ini object to get screen width and height?
Not sure about other IDEs but if you are debugging with Visual Studio you can access the call stack in one of the debugging tabs (usually one of the ones on the bottom right of the screen). This is a list of the functions that have been called leading up to the current location (the point where the break occurred). If you click on the last entry in the call stack before it enters the standard library (list functions) it should take you to the line that caused the problem, and allow you to inspect the values of the variables in the watch/auto/locals tabs.
________________________________Blog...
Quote:Original post by b_myeye
Hey,

do you load any file before you use the ini object to get screen width and height?


No, i initially thought that was the problem, only when i tried to load a file before doing so, i could never get the load function to work.
I would bet that the problem you were having is that you tried to call the load() function in the global scope, i.e. outside some other function. Apart from variable definitions you can't put non-declaration code outside functions.
Shame on your compiler for compiling this. const variables should be set to constants (known at compile time). THis may be causing you issues.

Also, if you are initializing your variables at file scope, you cannot guarantee that "ini" already has a correct value before you initialize you screen size variables - so it is likely returning NULL. This is a recipe for disaster.
Quote:Original post by rip-off
I would bet that the problem you were having is that you tried to call the load() function in the global scope, i.e. outside some other function. Apart from variable definitions you can't put non-declaration code outside functions.


I am pretty sure thats the problem, but how exactly would i call the load function in the right scope?
Quote:Original post by gpu_fem
Shame on your compiler for compiling this. const variables should be set to constants (known at compile time). THis may be causing you issues.

Actually, it's perfectly legal in C++ for const variables to be initialized dynamically.

Quote:Also, if you are initializing your variables at file scope, you cannot guarantee that "ini" already has a correct value before you initialize you screen size variables - so it is likely returning NULL. This is a recipe for disaster.

Globals with dynamic initialization are guaranteed to be initialized in order of appearance within a translation unit, which means that ini will be constructed before SCREEN_WIDTH and SCREEN_HEIGHT are initialized. Whether or not the default constructor for CIniFile is a reasonable choice is another story.

edit: grammar

[Edited by - SiCrane on June 9, 2009 7:45:19 PM]
Quote:Original post by gpu_fem
Shame on your compiler for compiling this. const variables should be set to constants (known at compile time). THis may be causing you issues.

Not so. Consider the following code:
void example(int x){   // this is legal, but not known at compile time.   const int whatever = x;}


Quote:
Also, if you are initializing your variables at file scope, you cannot guarantee that "ini" already has a correct value before you initialize you screen size variables - so it is likely returning NULL. This is a recipe for disaster.

In a single file, you have guaranteed order of initialisation. It is across files that cause issues. However, in this case the INI constructor probably initialises it to "empty", so yes there will be NULL pointers.

Quote:
I am pretty sure thats the problem, but how exactly would i call the load function in the right scope?

One hackish way is like this:
CIniFile load(const std::string &path){    CIniFile file;    file.load(path);    return file;}CIniFile ini = load("whatever.ini");

But I wouldn't recommend this approach. It depends on CIniFile respecting the rule of three also.

I think it is best to do this inside main. The primary reason is error handling, outside main there is very little you can do. Because the ini file is external, it needs to be treated as any other form of input and needs to be tested to ensure its correct. You can handle absent values by using defaults, or perhaps informing the user their ini file is corrupted if you cannot read the correct values. But you certainly should not crash for something like this.

Move all the code inside main, and your problems disappear [smile]. Well, not entirely. After all you might be relying on the global values of SCREEN_WIDTH and so on through a number of functions. You could either make them non-const (which is again a bit of a hack) or find other ways to communicate such information. The "best" method depends on the exact kind of information you are trying to access.

This topic is closed to new replies.

Advertisement