Mysterious access violation

BlitzMax Forums/BlitzMax Programming/Mysterious access violation

Pineapple(Posted 2014) [#1]
The pertinent line of code:

Local rgb%=img.ReadPixel(cellx+i,celly+j)


It's crashes at coords 0,6 or 0,12 depending on whether I added the following line immediately before the aforementioned one.

Print img.format


The pixmap is 500 by 250 pixels.

Here's what the surrounding code looks like.



What's going on here? The only change since when it was functioning normally is that now I'm iterating through an array of pixmaps loaded from a gif using Brucey's FreeImage rather than one static image loaded with the native LoadPixmap function. The crash always occurs on the first pixmap.


Pineapple(Posted 2014) [#2]
It looks like I probably found a fix, though it's hackish. Where I get the pixmap data from the loaded TMultiFreeImage I paste the data into a newly created pixmap and run the new one through the function. Still, why is this happening in the first place?

Edit: Nope, now I'm having other mysterious problems with entirely separate code. I have no idea what's happening with this. I've written the better part of a GIF loader already, I guess I'll finish that and try using it instead?


xlsior(Posted 2014) [#3]
Have you tried running it in debug mode, to see what it's actually complaining about?


Pineapple(Posted 2014) [#4]
I have, but it hasn't provided any useful information.


Brucey(Posted 2014) [#5]
Where I get the pixmap data from the loaded TMultiFreeImage

Are you loading an animated gif?

If you are doing it manually (i.e. using lockPage() and unlockPage()), you need to copy the pixmap data from the locked TFreeImage before you stop referencing it (i.e. you don't have a variable holding the TFreeImage object). The pixmap inside the TFreeImage object is "static", rather than dynamically allocated, and so when the TFreeImage object no longer has any references to it and is garbage-collected, the pixmap data becomes invalid.

The toAnimImage() method shows an example of usage, where copies of pixmaps are taken.

As far as I am aware, the TFreeImage obtained from the TMultiFreeImage will remain valid even after discarding the TMultiFreeImage object - so long as you still have a reference to the TFreeImage object.

Calling Free() on a TFreeImage object will also invalidate the pixmap data obtained via getPixmap().

HTH


Pineapple(Posted 2014) [#6]
Brucey, this is what I have now, based on one of the examples:

	Local in:TMultiFreeImage=LoadMultiFreeImage(dir+"input.gif")
	Local pix:TPixmap[]=New TPixmap[in.pageCount()]
	Local i%=0
	While in.hasNext()
		Local gpix:TPixmap=in.getNext().getPixmap()
		pix[i]=CreatePixmap(PixmapWidth(gpix),PixmapHeight(gpix),PF_RGB888)
		pix[i].paste gpix,0,0
		i:+1
	Wend
	in.free


Pasting the pixmap instead of using the original has solved the access violation but now I'm having bizarre bugs with my own GIF exporting code. It could be my own mistake but I can't imagine what the cause would be, it's never had these issues in the past.

edit: Okay, everything seems to be working now, with one exception. It seems to happen regardless of the input image I use. It's definitely a problem with the FreeImage loading.

Some info about the program: The intention is to load a GIF, pass each frame through an image filter I wrote, and output the result.

Here's the input GIF:


Here's what happens when I export the GIF as-loaded with my own code, no changes made whatsoever:


Here's one frame, isolated and exported with SavePixmapPNG, implying the problem is with the loading and not the exporting:


The color of the noise is always the same red, regardless of the inputted GIF's palette. The GIFs I've tested were from Photoshop's "Save for web" option, using various settings.


Brucey(Posted 2014) [#7]
You need to use the options flag GIF_PLAYBACK :
Local in:TMultiFreeImage=LoadMultiFreeImage(dir+"input.gif", true, GIF_PLAYBACK)


As per the Appendix in the official documentation available here, it states :

Transparency is supported individually for all pages, the first entirely transparent index in the table is used, the rest of the table will be entirely opaque.

The background color is only set and stored for page 0, but requires that the global palette be set in order to use it properly.

The GIF_PLAYBACK load flag option will load a single page as a 32bpp image with transparency by displaying each page from 0 up to the specified page, obeying the transparency overlaying and gif disposal methods. Note that it does not actually play the image animation in a displayable way. It "plays" the image internally from page 0 to the page requested, returning a single still image of what that frame would really look like.



What you are seeing (with the red) is the raw data for each page.

Also, you can probably just do this :
pix[i]=gpix.Copy()

instead of creating a new pixmap and pasting from another.

HTH

:o)


Brucey(Posted 2014) [#8]
btw, you should be wary using BRL.PNGLoader and BaH.FreeImage - since they each have their own copies of LibPNG. Unless you are using my latest BaH.FreeImage and my updated BRL and PUB modules, there is a reasonable chance of your application crashing when using PNG-related functions.
Ideally you would use one or the other, but not both together. FreeImage can Load/Save all the formats anyway.

I've not had any issues using FreeImage in my projects. Issues tend to end up being user-related rather than library-related. ;-)


Pineapple(Posted 2014) [#9]
The wrapper function for LoadMultiFreeImage has only got two arguments, the filename string and readonly boolean.

Just checked, I'm using the 1.06 version of the module and the latest version is 1.07, I'm updating and hoping that fixes it


Pineapple(Posted 2014) [#10]
Okay, there's an argument for the flags but GIF_PLAYBACK isn't defined. What should I be using?

edit: It's 2 in FreeImage.h, will report back once I've got the damn thing to compile correctly.


Brucey(Posted 2014) [#11]
The lastest version (in SVN/Git) is 1.08. That's probably the one you want.

I've uploaded a copy of the source (for your convenience) here.


Pineapple(Posted 2014) [#12]
I'm getting errors with the linking. Building the module worked fine. At first I was getting maybe a couple hundred errors then I tried the solution here: http://www.blitzbasic.com/Community/posts.php?topic=91805

Now I'm just getting a few, all the same one.



Any ideas on how to fix this?

edit: What an adventure this is turning out to be.

I tried your bundle here: http://www.blitzbasic.com/Community/posts.php?topic=95220

Now I just get the error: "g++: error: unrecognized command line option '--stack=4194304'"

At the moment I'm downloading the TDM-GCC MinGW, see if it helps to use that instead.

Aaand nope, no dice. The bundle also introduced errors in compiling normally, without the FreeImage module.


Derron(Posted 2014) [#13]
Brucey works with GCC 4.7.x ... so you will have to check that TDM-versions. Also keep in mind to stay with "SJLJ"-exception-handling-builds (compared to DW2 ones).

Install MinGW accordingly!
Means: copy the lib files, overwrite ar.exe and ld.exe etc.

If you use modules from Brucey, it is better to use his "bmk"-sources to compile your own bmk.exe (do not forget to copy the "*.bmk"-files as they contain special configuration settings - eg for crosscompiling, default params etc.).


bye
Ron


Pineapple(Posted 2014) [#14]
I never did solve the module building issues, but I did manage a workaround. After loading the GIF using an old version of Brucey's FreeImage that I had compiled on Windows 7 in a previous BlitzMax installation I ran the array of pixmaps through this function:

Function processGIFtransparency(pix:TPixmap[])
	For Local i%=0 Until pix.length
		Local p:TPixmap=pix[i]
		For Local x%=0 Until p.width
		For Local y%=0 Until p.height
			Local orgb%=p.ReadPixel(x,y),rgb%=orgb
			Local j%=i-1
			While j>=0 And rgb & $ff000000=0
				rgb=pix[j].ReadPixel(x,y)
				j:-1
			Wend
			If rgb<>orgb Then p.WritePixel(x,y,rgb)
		Next
		Next
	Next
End Function



Pineapple(Posted 2014) [#15]
Wow do I need to pay attention to whether I've got the latest version of things. Updated to max 1.50 and now modules compile with no hassle at all. I don't feel smart.


BlitzSupport(Posted 2014) [#16]
There is a working .gif loader in the Code Archives, not sure if it would suit your needs, though:

http://www.blitzbasic.com/codearcs/codearcs.php?code=2207


Brucey(Posted 2014) [#17]
Apart from having to rewrite it in BlitzMax first? ;-)