🔒 Locked

Data Abort problem

Started by scottrick49 Apr 13, 2009 at 2:53 PM 5 replies 1k views

Original Post

Apr 13, 2009 at 2:53 PM

I am getting a Data Abort error followed quickly by an access violation:


Data Abort: Thread=8382b400 Proc=802bc670 'test.exe'
The thread 'Thread::go' (0x42fe2f6e) has exited with code 0 (0x0).
AKY=00080001 PC=0002952c(test.exe+0x0001952c) RA=001d0088(test.exe+0x001c0088) BVA=28000010 FSR=00000007
Unhandled exception at 0x0002952c in test.exe: 0xC0000005: Access violation reading location 0x00000010.

The IDE (vs2005) breaks in this function:


inline void Graphics::setClip( int16 x, int16 y, int16 width, int16 height )
{
	m_rcClip.x = x;
	m_rcClip.y = y;
	m_rcClip.dx = width;
	m_rcClip.dy = height;

	this->SetClipRect(&m_rcClip); //YELLOW Visual Studio ARROW at this line
}

Naturally, I thought the "this" pointer was null, but when you examine it everything looks okay. The pointer and all the object's members look valid. So I've been doing some digging, trying to figure out what causes these Data Abort errors. And one site recommended looking into the assembly and seeing exactly what it was crashing on. After some work, I found that it is crashing at function offset 6c:


; 179  : 
; 180  : 	this->SetClipRect(&m_rcClip);

  0004c	e59d3008	 ldr         r3, [sp, #8]
  00050	e2831024	 add         r1, r3, #0x24
  00054	e59d3008	 ldr         r3, [sp, #8]
  00058	e283200c	 add         r2, r3, #0xC
  0005c	e59d3008	 ldr         r3, [sp, #8]
  00060	e283000c	 add         r0, r3, #0xC
  00064	e5923000	 ldr         r3, [r2]
  00068	e2833010	 add         r3, r3, #0x10
  0006c	e5933000	 ldr         r3, [r3]
  00070	e1a0e00f	 mov         lr, pc
  00074	e1a0f003	 mov         pc, r3

I don't have much practical experience with assembly, but it looks like (?) de-referencing the this pointer is causing the problem. On a side note, this looked a little fishy, but I'm assuming its valid?


  0006c	e5933000	 ldr         r3, [r3]

So I guess my question is this: What could be causing this data abort error? It looks like de-referencing is causing the problem, but as I said, when I look at the this pointer in the IDE, all looks fine. Any help is greatly appreciated!

frob

Apr 13, 2009 at 3:04 PM

Quote:
Access violation reading location 0x00000010.

That line by itself implies that you are following a null pointer, and accessing the memory 16 bytes out from it.

Is m_rcClip valid? Is taking the address of it a valid operation?

Is the Graphics object valid before you enter the function? To check it, review the call stack at the time of the crash, and see what is calling the function. Drop a breakpoint before the function call and rerun. Verify that the object is not null, and that it points to a valid Graphics object.

scottrick49

Apr 13, 2009 at 3:08 PM

m_rcClip is valid. If I go up the call stack, the Graphics object is valid.

iMalc

Apr 14, 2009 at 1:46 AM

If the 'this' pointer was NULL then the four assignment statements before the call to SetClipRect would have caused an access violation first.
It would seem more likely that SetClipRect is a virtual function and the virtual function table pointer is NULL. 0x00000010 suggests that SetClipRect is probably the fifth virtual function in the class.

What would cause this is doing:

memset(this, sizeof(*this), 0);

or the equivalent using ZeroMemory. Never do that!

So, am I right or am I right?

scottrick49

Apr 14, 2009 at 11:11 AM

Yes, you are correct! I've never run into something like this before.

I am having difficulty determining how the virtual function table pointer is getting written over though. I have been stepping through the object construction and I think it is always getting setup correctly. Any suggestions? I am not able to use data breakpoints, either.

edit: one thing, I notice that the graphics class uses multiple inheritance; it is the second class it inherits from which is getting its vtable overridden. I don't know if that info is helpful or not..

iMalc

Apr 14, 2009 at 2:32 PM

Okay, well short of spotting the obvious things that would clear the entire class to zeros, I can only suggest to start cutting bit out until it works, or stepping through all sorts of bits of code that use that class.
If you can simplify the code down to something fairly short and it still happens, then post the code here. Otherwise all I can really say is good luck, I'm sure you'll find it soon!

ApochPiQ

Apr 14, 2009 at 3:10 PM

Post your code for the class definitions, particularly where you are using multiple inheritance, and the constructor implementations. MI has some tricky cases (especially in C++) that can cause weirdness with your vtable pointers. Also note that using virtuals inside a constructor is technically undefined behaviour, so it you're doing anything like that, it's probably related to your crash.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.