580x819 picture
Archives Forums/Blitz3D Bug Reports/580x819 picture
| ||
| I think I found a quite surprising crash with Blitz3D. When you try to load a 580x819 sized picture, the LoadImage (and LoadTexture) function will crash. Its not specific to a certain file : Create a picture of that dimension, whatever the type is (jpg, bmp, png) it will crash. It wont crash anymore if a dimension is changed by even 1 pixel. A 819x580 picture will not crash either. The code to reproduce the crash cant be simpler and should work (well, crash) with any 580x819 picture : Graphics3D 800,600,32,2 img = LoadTexture("580x819.jpg") DebugLog "This will not appear, should crash before." |
| ||
| You should only use power of two textures, best if squared for greater compatibility. Also, always specify "1" (Color) for the texture flag; i.e. LoadTexture("texture.png", 1). These two are the most common problems with newest video drivers (however not so new by now), though the first one always was an issue on some cards, expecially ATI ones. |
| ||
| Sir I think you totally missed the point. Its not about texture size, its about picture file loading. BOTH function LoadImage() and LoadTexture() will CRASH when called on that SPECIFIC 580x819 resolution. They dont return a 0 result, they just crash the program. Its doesnt seem to be a problem specific to my config, I had users using my tool reporting this problem. I just used LoadTexture() in my example, but I could have providen the following example for the exact same result : ================================================= Graphics 800,600,32,2 img = LoadImage("580x819.jpg") DebugLog "This will not appear, because Blitz will crash before that." ================================================= I have to say I really dislike that "hotline syndrom" feeling : you clearly explain your problem but the 'technician' provides a totally unrelated answer, giving you the impression that he didnt really listen to you. Nothing personnal here sir, I suppose you wanted to help which is always a good thing, but apparently you didnt took time to carefully read the post. :/ This being say, I might be the one wrong in my present bug report, but regarding the example I provided it leaves little room for doubt. |
| ||
| Have to say maybe your post wasnt intended to be an answer to the bug reported but a side note, in which case this makes my rambling invalid. @_@' ... However that would still be quite a out-of-topic bur report answer, è_é! |
| ||
| Sorry sir, it wasn't a side note, I just tought that you put 580x819 in your topic as an arbitrary non-power of two size and I ignored the LoadImage part since I focused on the code which on some configurations crashes if you load a texture with alpha, so I assumed that this was the only issue. Didn't want to sound like the 'know it all' guy, just misinterpreted your post and didn't have the time to check the code which would have revealed that it crashed anyway. Anyway, now I have tested various images of various formats and I must agree with you: this specific resolution (maybe more? I should make a little program to test it out) are causing a Memory Access Violation. CreateTexture and CreateImage do create a texture of that particular size though. Blitz Plus features the same issue too. |
| ||
| Thanks for your checking, and not getting angered by my rambling :) I will now be searching for a way to prevent this crash on blitz3D programming forum. |
| ||
| Wow,... that's a strange one. I just had to confirm this myself, and it does it here too. It's an odd resolution, so I can understand how this hasn't come up before, but I'm really interested in what the problem/solution is. |
| ||
| That's a scary one. I am pretty sure Mark did NOT add this "feature", why should he do something like: if w=580 and h=819 then MAV It really doesn't make sense. I would rather suspect microsoft as the fishy part, since they already implemented browser backdoors be checking if a jpg contains executable code and then execute it blindly ... I mean, how stupid can a hundred programmers be? BTW CreateImage does not MAV. |
| ||
| Wow.. That's weird, and worrying. Certainly there's some special quality about those dimensions, has anyone tried with 1160x1638 or something? They seem like randomly plucked from a hat, but there must be a reason why those values specifically cause an issue. I am pretty sure Mark did NOT add this "feature", why should he do something like: if w=580 and h=819 then MAV It really doesn't make sense. I would rather suspect microsoft as the fishy part, since they already implemented browser backdoors be checking if a jpg contains executable code and then execute it blindly ... I mean, how stupid can a hundred programmers be? Totally agree... and as for 100 programmers, I'd go with too many cooks syndrome ;) |
| ||
| About the special quality, I tought a little about it, but the only thing I can think of are the ratio or the number of pixels (475020). Neither seems to give an odd/special number. Its not about the file weight either since it happens on both bmp/jpg/png. And about the ratio : As far as I tested its not the problem. 1160x1638 does not crash. |
| ||
| Just out of curiosity, I reversed the dimensions and it loads just fine. I guess that would rule out anything dealing with the total pixels in the image. Also, since it does this with *any* (.jpg,.png,.bmp,...) image, it's got nothing to do with file sizes or content. It makes me wonder if there are any other resolutions that cause a problem. Maybe write up a chunk of code that creates an image and reads it back in, then iterate through a bunch of loops to find out. |
| ||
| GREAT NEWS! I found another "magic resolution". Its good news in the sense it could give us a lead. The bad news its I dont see much of a relation for the new magical resolution is 900x1347, which has a quite close ratio to 580x819 ... close, yet different. Other than making the supposedly stable verion I released NOT stable, it suggests that there are yet others magical resolutions to be found. Im now trying to find relations between those two sizes in the hope of making a rule to exclude such magical pictures before trying to load them ... |
| ||
| How are you finding these? This is definitely some kind of bug, but it's like finding a needle in a haystack and now you have found 2 of them. Just out of curiosity, have you tried an older build of Blitz? |
| ||
| Nope, didnt try older versions, this might be a good idea tough. Im making a tool that scans large collections of pictures to find duplicates, and since each version is released to public, that makes a pretty wide array of pictures to be tested, with very various situations. Those "magical sizes" tough only happened a few times are those are indeed weird sizes. I can exclude magical resolution pictures by doing a condition for each known "magical size", however Ill never be sure if a new will arise at some point. Im not used to that bugs forum, what are the chances/delay to see that bug corrected ? Should I not count on that ? |
| ||
| This is of particular interest to me, ebcause I am working on an application which deals with converting images selected and loaded by the user, so it's very likely that sooner or later, an image with such a resolution may pop up. I'm gonna work on loading in various images on a range of sizes, hopefully (and painstakingly long/laboriously) will reveal as many of these numbers as possible. It's way beyond me, but perhaps if anyone's more savvy with technio-babble and programming that knows something of the BlitzSDK or so, is there anything significant in the core coding of the "LoadImage" command? ---------- It's a fairly critical kinda bug, especially as it now seems likely there's potentially more of these "magic resolutions" that could pop up unexpectedly, but then again... I'm not sure that it's really gonna be a priority case to be honest. Also, as the bug is quite obvious once discovered to be due to the image resolution, then it can always be worked around (albeit awkwardly with resized images or whatnot). Of course, I'm in no way any authority on the subject, just speculation to be honest. |
| ||
| Hi, Okay, think I've found this - new updates for Blitz3D and BlitzPlus are now available from the product updates section of the Account page. The bug appears to be due to FreeImage reading one more byte than it should when converting bitmaps from one format to another. 99% of the time, this is harmless. However, now and then (eg: when the size of a memory block is 'just right' etc) you end up reading from unallocated memory and causing an exception. |
| ||
| Excellent ! That really gets me out of trouble : ) Oh ? version 1.100 ? Heh, altough thats totally illegitimate and maybe somewhat childish, I feel "proud" a little that my bug report caused the 1.100 version to appear ... Do I win a candy ? :D Anyways, thanks alot for the quick response & update, Mark : ) |
| ||
| I tested this with my FreeImage 3.10.0 module and it didn't crash. |
| ||
| Thanks Mark. I know it's been said before, but I'll say it again. Your product is outstanding and the support is incredible. Ok, enough praise,... get to work on Blitz3d 2.0! :p (Sorry, couldn't help myself) |
| ||
| Bah, he didn't include full DX9 support. |
| ||
| Fantastic, Mark - Thank you very much for addressing this :) (And I must apologisde if my comment of "... I'm not sure that it's really gonna be a priority case to be honest. Also, as the bug is quite obvious once discovered to be due to the image resolution, then it can always be worked around (albeit awkwardly with resized images or whatnot)." Didnt inspire much confidence. |
| ||
| Thanks Mark! |
| ||
| Thanks Mr. Sibly ! |
   |