NewsForumsCodeLogsGallerySpecsSearch

EXCEPTION_ACCESS_VIOLATION

BlitzMax Forums/BlitzMax Programming/EXCEPTION_ACCESS_VIOLATION

GfK(Posted 2010) [#1]
Why am I getting this all the time lately instead of any meaningful error??

Clearly there's something wrong in my code but it isn't telling me where, and the debugger doesn't kick in, either. Seems to happen whenever there's an error anywhere but in the main thread.

Surely this isn't right?


ziggy(Posted 2010) [#2]
I think this is what you get when there's a runtime error in release mode (instead of just exiting application) in latest BlitzMax. Be sure to not be running a Release version of your game.


Thareh(Posted 2010) [#3]
I get this aswell - in both release mode and debug mode.
It never tells me the error, but it points to the line where the error occurs in debug mode.
Oh, and I installed BlitzMax yesterday - fresh install with latest BlitzMax & MaxIDE.


skidracer(Posted 2010) [#4]
Local f:Int Ptr
f[0]=0 ' memory address zero is mine!



It's a MAV handler that returns control to the debugger. Earlier versions of BlitzMax made such hardware exceptions look the same as runtime errors but they are not and I think are now more safely managed.

[ot] I personally would only think of publishing singlethreaded dx7 apps for windows release with bleeding edge dx9 multithreaded shenanigans attempted once game itself was totally bug free and BlitzMax136 becomes a little more stable.

All of your getactivehwnd calls that you posted in another thread [/pun] should go also. The Debugger and any apps attempting to override graphics window behavior should IMHO be using findwindowbyclassname or whatever its called to derive handle for activating graphics window (they don't). Window activation in DirectX is THE most complex problem I have ever faced so you should tread very lightly in this department.

IMHO Fullscreen / window toggling should ideally be managed by BlitzMax Graphics drivers not API hitting user code.


Arowx(Posted 2010) [#5]
I've recieved this and in debug mode it points to the GrabImage() Function, so I used the grab image sample program, tweeked it to always grab the current image and then paste it again and recieved the same error but in a totally diffrent area of the DX9 graphics driver!

The program takes a while to drop out/fail, just running it a third time!

Graphics 640, 480
SetBlend ALPHABLEND


Cls

SetColor 255, 0, 0
DrawLine 0, 0, 32, 32

SetColor 0, 255, 0
DrawLine 32,0,0,32

SetColor 0, 0, 255
DrawOval 0,0,32,32

Local image=CreateImage(640,480,1,DYNAMICIMAGE|MASKEDIMAGE)
GrabImage image,0,0

Local frameCounter:Int = 0

Repeat

	Cls
		
		DrawImage image, Rnd(600) - 300, Rnd(440) - 220

		SetColor 0, 0, 255
		DrawOval 0, 0, 320, 320
		
		SetColor 255, 0, 0
		DrawLine 0, 0, 320, 320
		
		SetColor 0, 255, 0
		DrawLine 320, 0, 0, 320
				
		'every third frame grab image
		
		SetColor 255, 255, 255
		GrabImage image, 0, 0

		DrawText frameCounter, 0, 0
		frameCounter:+1
		
	Flip

Until AppTerminate()


Still waiting for the third run to Fail, see below!

Edit added framecounter and larger graphic.


Arowx(Posted 2010) [#6]
Got it over 800 very slow frames the error looks like the same place...

BRL.mod/pixmap.mod/pixmap.bmx (183)
Function Create:TPixmap( width,height,format,align=4 )
Local pitch=width*BytesPerPixel[format]
pitch=(pitch+(align-1))/align*align
Local capacity=pitch*height
Local pixmap:TPixmap=New TPixmap
pixmap.pixels=MemAlloc( capacity ) <--- <* Here! *>



Fourth run same place about the same number of frames 802!
Ditto fifth Run,

Can anyone else recreate this problem?


skidracer(Posted 2010) [#7]
nice! this one leaks horrendously, are other drivers ok?
Graphics 640, 480
Cls
image=CreateImage(640,480,DYNAMICIMAGE|MASKEDIMAGE)
While Not KeyHit(1)
	GrabImage image,0,0
Wend



Arowx(Posted 2010) [#8]
OpenGL - looks quite solid, memory fluctuates but stays low (20-30Mb)! and extremely fast!

DX7 - memory increases quite dramatically but then drops and cycles (still goes to very high values though about 200Mb)

DX9 - memory races away jumping into hundreds of Mb and reaching 2Gb before the app died, seems to stair climb stepping up and down on the way!


xlsior(Posted 2010) [#9]
and reaching 2Gb before the app died


2GB is the max. amount of memory that can be allocated to a single process in 32-bit mode, so that would explain the crash...


*(Posted 2010) [#10]
trust OpenGL to be the solid one LOL, I did state ages ago that max should go OpenGL only :)