Archived

This topic is now archived and is closed to further replies.

Esap1

this Pointer is NULL

Recommended Posts

Im having an Access Violation in a Function, which is Called from a Member funtion of the CLightSystem. Whats weird is, the Debugger(MSVC6), says that the *this pointer is 0x00000. So all the member Variables are also Zero. What does this mean, wat coulda happened?

Share this post


Link to post
Share on other sites
But it is, I used new and everything, would it be able to get through most of the function if it wasnt Initlized?

Share this post


Link to post
Share on other sites
Ok.

Did you use memset on a local variable? Copy a large string into a small buffer? Try checking any memory copies and sets and check for over runs.

Or you can take the easy route. In your debugger, set a memory watch point at the location of the pointer (not what it looks at). Then set a break point so that your program halts when the memory contents at that location change.

If you can''t do that. follow the value line by line. It will change when something messes with it.

Lastly. Are you actually using the correct variable as a pointer?
i.e passing a but using b.



D.V.

--------------------------
Carpe Diem

Share this post


Link to post
Share on other sites
The best solution to a solving a problem, is to not think of one.

Go drag your project into the trash can, and then make a new project file, and start all over, making something new instead. Come up with an idea thats easy, that will be easy to make, so you can have good self esteem.. Make a blank window for example. Thats easy.. Try and market it too, you might get a few sales.

Its sure late, isn''t it. 4:45 comes early.

Share this post


Link to post
Share on other sites
All sarchasm aside, I have had this happen to me before. Most of the time it''s when I do something really, really bad, like call win32 operations on an invalid file handle. My last problem like this was when I wasn''t synching two threads correctly, and so the worker thread was working on an uninitialized file handle, but I wasn''t checking return values so I didn''t know things were going wrong. It took 3 or 4 calls before the program ate itself, and at that point all I had was a weird NULL this pointer, or a stack pointer that seemed to be pointing the wrong place (stack-local variable constructors not doing the right thing).

What you need to do is put a breakpoint where you see "this" as NULL. If the first time you hit the breakpoint it''s not NULL, you just have to keep running until it becomes NULL or corrupt. Also, pop back a call on the stack and make sure all the pointers in the calling function look kosher. It just takes line-by-line stepping while watching all the variables you can think of until you see some change unexpectedly; then you''ve got your problem. Good luck.

Share this post


Link to post
Share on other sites
Example:


class type { int x; public: int function() { return x; } };

int main()
{
type* p = 0;
int x = p->function(); // error: causes access violation

return 0;
}


If you have some linked list or other custom container code going, make sure you have a valid pointer. It''s quite possible to go through a whole function with a null this pointer, but only if it accessed in the function. In the previous example, the function body contained this line:


return x;


...which is merely shorthand for this (no pun intended):


return this->x;


Since this is null, accessing x through this causes an access violation in Windows. However, it is important to understand that calling the function does not of itself generate an access violation.

Now, earlier I said it is okay to call certain member functions on a null pointer. Obviously, any static member function will work fine, since it can''t access the this pointer. There are certain functions that may need to access the this pointer''s value, but will work fine if the pointer is null.

Example:


#include <iostream>

class type
{
public:
void function()
{
std::cout << "this is " << ((this) ? "not null" : "null") << std::endl;
}
};

int main()
{
type* p = 0;
p->function(); // ok, only uses value of p itself
}


(Note: Simply calling a virtual member function will most likely access the this pointer, thereby causing an access violation. )

What Stoffel and DeltaVee are saying is that it''s possible that you have accidentally overwritten the pointer value whose member function you are calling, by using memset or some mistake in your loop control code.

Stoffel is correct in saying that some Win32 API functions can cause some -extremely- wierd behavior when you pass them invalid parameters. (I suppose that if they checked every parameter, Windows might be a bit too slow. )

You should always check return values from C-style code. This method of error-handling is frustrating, because it messes up my nice, clean code, so I wrap the Windows stuff in a class. For example:


class ddraw
{
public:
ddraw(HWND window = 0);
ddraw(int width, int height, int depth, HWND window = 0);
~ddraw();

LPDIRECTDRAW operator -> () { return p; }

private:
LPDIRECTDRAW p;
};

ddraw::ddraw(HWND window)
: p()
{
HRESULT hr = DirectDrawCreate(0, &p, 0);

assert(SUCCEEDED(hr));

hr = p->SetCooperativeLevel(window, DDSCL_NORMAL | DDSCL_NONEXCLUSIVE);

assert(SUCCCEEDED(hr));
}

ddraw::ddraw(int width, int height, int depth, HWND window)
: p()
{
assert(width and height);

HRESULT hr = DirectDrawCreate(0, &p, 0);

assert(SUCCEEDED(hr));

hr = p->SetCooperativeLevel(window, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN)

assert(SUCCEEDED(hr));

hr = p->SetDisplayMode(width, height, depth);

assert(SUCCEEDED(hr));
}

ddraw::~ddraw()
{
p->RestoreDisplayMode(); // outdated, but necessary for old interfaces
p->Release();
}


So...what are you trying to do with that pointer? Are you sharing the pointer between threads? Is the object part of a class factory? Or in a standard container?

Share this post


Link to post
Share on other sites