Tracking down memory access violation errors
BlitzPlus Forums/BlitzPlus Programming/Tracking down memory access violation errors
| ||
| I occasionally experience my game crashing out in a memory access violation but I suspect something fishy. Basically I preload cars that I rotate in memory, if all features are enabled, a total of 8 x 4 x 72 (2304 small bitmaps that is) are stored into the memory. The actual process of loading and rotating the images never fail, however when I do a "ImagesCollide" using the bitmaps the game sometime crashes with memory access violation. I am very picky on sizing images and clearing down before GFX mode changes etc. I log all the loadimage / createimage / freeimage commands to a log file to make sure I am not missing anything, and I am also checking that when it crashes, all my variables and pointers point to valid images without any out of range stuff. What are the most common problems when this error occurs using ImagesCollide? I can't really post the code here as it would be 250 kb worth of code, I am more after some suggestions on troubleshooting it and what generally causes this. Could this possibly be something with problematic in Blitz and the only reason for encountering it is due to using such a large number of bitmaps in memory? |
| ||
| If you can load such a big amount of images without problems, then you should not have any problem checking for collisions. One thing that comes in my mind, is that you could have ran out of images frame. In fact, the imagescollide syntax looks like: ImagesCollide(image1,x1,y1,frame1,image2,x2,y2,frame2) Perhaps you refer to non-existant frames for some of your images. Check it out...; alternatively, you can change imagescollide with imagesoverlap (taking away the frames parameters), and see if solves the error. If so, it could definately be some 'out of frame' kind of problem. I assume, also, that all your images are declared as global, or are loaded in one array (which is global by default). If loaded in an array, check also if you ran out over the array boundaries. Good luck, Sergio. |
| ||
| I just checked and ImagesCollide does generate correct error messages for ImageDoesNotExist and ImageFrameOutOfRange cases. Any chance of logging the image sizes of the images involved b4 the call and the coordinates? Are you using image frames? |
| ||
| It is an odd error as it does not occur very often. To troubleshoot this matter further what I've done is to create a loop just before game launch that imagecollides all my images, and maybe one out of a hundred launches results in this crash. I do use anumated images, but I can during a crash verify that all the involved variables for positioning and what frame it is is within my valid boundaries. It's a tricky one to track down just because it doesn't happen very often, and I am equally baffled each time it does crash. I am starting to suspect that the error may lay when creating the animated images. I load a set of cars into memory and I rotate them onto a large number of frames. I am not using imagerotate as it is too small, but another routine that uses writepixelfast in a lockbuffer state. Saying that I have already checked that those animated images are never writing outside the coordinates of the image frames etc. |
| ||
| Have you tested it on any other computers? It could be a memory problem on your machine otherwise. |
| ||
| Yep, tested on other machine too. |
| ||
| Are you using freeimage at any point. Check out the online docs on freeimage for a further explanation. This particualr beauty gave me weeks of errors very similar to the one you're experiencing. |
| ||
Yep, I am quite sure I freeimage all the stuff that I load. I have created a quite extensive debugging system to track this down, by logging all load/create image and free image commands, here's an extract of the logfile:---> LoadUnloadMenuFX(options,load) + LoadAnimImage: L_GfxTiles Width=80 Height=80 StartFrame=0 Frames=2 (MemRef#:170795768) + LoadImage: MenuGfxTop Width=800 Height=80 (MemRef#:11313088) + CreateImage: L_GfxFlag Width=800 Height=600 (MemRef#:170794264) + CreateImage: MenuGfxStrips Width=2 Height=600 Frames=400 (MemRef#:170795816) - FreeImage(L_GfxTiles) - FreeImage(L_GfxFlag) So far I haven't seen a single image that wasn't freed properly, but I am still happy to hear suggestions, no matter how primitive they may be... I may have missed something silly =) |
| ||
Yes, but do you re-use any image handles during your game.IMtemp=LoadImage "gfx/talt.bmp" freeimage IMtemp IMtemp=LoadImage "gfx/fume.bmp" Calling freeimage alone is not enough, you have to zero out it's handle as well. Otherwise you get VERY unpredictable errors (usually missing images) that occur randomly in future graphics operation. Use this logic (probably best to make a function) and see if it helps if IMtemp<>false then freeimage IMtemp : IMtemp=false According to Mark this is expected behaviour and not a bug, but he did concede it should have been mentioned in the manual. |
| ||
| Any chance you can replace the 2x600 x 400, thats a pretty extreme requirement for the DX texture manager and you could maybe put them all on a single map and blit strips from there? Or maybe just disable that effect and see if lesser / smaller image requirement stops the crashing. Is this Blitz2D or BlitzPlus? Is the crash from ImagesCollide car to car or car to a big image, and if so what size? I'm thinking there could also be memory exception from particular coordinates, maybe blitz comparing one line of pixels too many below or to the right so logging of actual parameters would be interesting. |
| ||
| Good stuff, thanks for the suggestions. Simon, I am currently not always resetting the variables to 0. I did initially go for the if xxx <> 0 then freeimage xxx: xxx=0 but I figured that when I tidied up my code so much it shouldn't be necessary to check whether the image existed as I for a fact know all the images that are loaded at any given time. I will however implement what you suggested, well worth it as I do reuse the same handles. Skidracer, I'm using Blitz2D. The extract above is for a menu effect rather than in game where it sometimes can crash, but I will change it to use DrawBlockRect instead. |
| ||
| Ah, ok. As long as you are confident about the code. I found my computer getting quite randomly upset when my lazy coding called freeimage on already zeroed variables. |
| ||
| Blitz error trapping and debugging sucks ass ,, IF without ENDIF shouldn`t pop up because of a missing bracket on a totally unrelated command in a loop |
   |