EXCEPTION_ACCESS_VIOLATION Any obvious stupidity?

BlitzMax Forums/BlitzMax Programming/EXCEPTION_ACCESS_VIOLATION Any obvious stupidity?

Sledge(Posted 2010) [#1]
I'm getting EXCEPTION_ACCESS_VIOLATION on the file requester -- never the first time, usually (but not always) the second, load & save both. I'm guessing I'm doing something dumb re closing streams. Here's the loading code:
Function LoadFile()
	FlushKeys
	Local filter$="LEdit files:ledit;All Files:*"
	Local filename$=RequestFile( "Select load file",filter$,False)
	If filename$ = "" Return

	Local fileIn:TStream = ReadStream(filename$)
	TLine.list.clear()
		Local lineCount:Int = ReadInt(fileIn)
		For Local i:Int = 1 To lineCount
			Local ax:Int = ReadInt(fileIn)
			Local ay:Int = ReadInt(fileIn)
			Local bx:Int = ReadInt(fileIn)
			Local by:Int = ReadInt(fileIn)
			Local locked:Byte = ReadByte(fileIn)
			
			TLine.AddAt(ax,ay,	bx,by,	locked)
		Next
	CloseStream(fileIn)
End Function

Anything stand out there? For context, it's just a bunch of line-defs being loaded as I'm having a faff with Chipmunk and wanted to whip up an editor.


Jesse(Posted 2010) [#2]
if you run it in debug mode it should tell you what line the error is in.
you might be running past the end of the file.


Sledge(Posted 2010) [#3]
Nope, there's no error given in debug mode with the EAV dialogue (see where this has popped up elsewhere). It happens even if I cut the loading short AND on the save requester so running past EOF can't be it either. If the way I assign and free the stream looks kosher then I'm at a bit of a loss...


Sledge(Posted 2010) [#4]
Okay I isolated the offending code into a standalone program and it still crashes. Here's the source:
SuperStrict
AppTitle$ = "File Requester Crash Test" 
Graphics 500,360

While Not ( KeyHit(KEY_ESCAPE) Or AppTerminate() )
	Cls
	If KeyHit(KEY_L) LoadFile()
	Flip
Wend


Function LoadFile()
	FlushKeys
	Local filter$="LEdit files:ledit;All Files:*"
	Local filename$=RequestFile( "Select load file",filter$,False)
	If filename$ = "" Return

	Local fileIn:TStream = ReadStream(filename$)
		Local lineCount:Int = ReadInt(fileIn)
		For Local i:Int = 1 To lineCount
			Local ax:Int = ReadInt(fileIn)
			Local ay:Int = ReadInt(fileIn)
			Local bx:Int = ReadInt(fileIn)
			Local by:Int = ReadInt(fileIn)
			Local locked:Byte = ReadByte(fileIn)
		Next
	CloseStream(fileIn)
End Function


This is the data file: test_ledit.ledit

Here's what happens for me when I repeatedly load the file:


As you can see there's no debug info. The crash happens while the requester is waiting for you to click on a file -- I didn't even get a chance to select one there. I'll probably shift this over to the bug reports forum if there's nothing obvious, but I can't help thinking it's me :D


Jesse(Posted 2010) [#5]
I tried it and it works fine here. Windows XP sp3 I also tried it on my wifes laptop with windows 7 and it works fine.
Try to see if rebuilding all modules fixes it. It might just be a corrupted module.
what Bmax build are you using?


Chalky(Posted 2010) [#6]
I just pressed L 25 times in a row, and it worked perfectly. I ended it, recompiled and did the same again - no problems (WinXP SP3 - BMax 1.39).


Sledge(Posted 2010) [#7]
Tried it with 1.38 and 1.39, and rebuilt all modules with several versions of MinGW -- still resolutely EAVs :( Thanks for testing the code guys, would you mind trying to run the binary that Max spits out for me? Have uploaded it here (it has been AVG'd):

FileRequesterCrashTest.debug.exe

Should help determine whether my Max installation is squiffy.

I just pressed L 25 times in a row, and it worked perfectly.
Are you opening the test file each time, BTW? Continuous cancelling doesn't seem to cause the problem.


Shambler(Posted 2010) [#8]
Your .exe works fine for me, opening the test file each time no problem.

Windows Vista SP2.


Chalky(Posted 2010) [#9]
Your .exe works fine for me, opening the test file each time no problem

And for me - 15 times without a single EAV.


Sledge(Posted 2010) [#10]
Thanks everyone -- visited the folks today, tried it on their XP machine and it ran fine. While it's quite an annoying problem it would appear to be my XP installation at fault, which is the preferable situation.


GaryV(Posted 2010) [#11]
Sledge: I read this thread based on your bug report. I gave your compiled example a test on four different XP SP2 systems here at the house and I had no issues.


Czar Flavius(Posted 2010) [#12]
Try putting in a debug stop and going line by line the get the percise line it happens on.