iminiB3D, EXC_BAD_ACCESS, and data alignments
BlitzMax Forums/MiniB3D Module/iminiB3D, EXC_BAD_ACCESS, and data alignments
| ||
| Hey all, So, I'm using iminiB3D for one of my current projects, and I've discovered something that struck me as rather odd. Attempting to load .b3d files results in an EXC_BAD_ACCESS in the first PeekFloat called by LoadAnimB3D, but only if running on the device itself, not in the simulator. Turns out this wasn't just my own code playing up: the exact same error happens when trying to run the unmodified Zombie demo, included with iminiB3D. After some experimentation and poking around, I have discovered that apparently ARM processors really don't like being asked to read floats from memory offsets not aligned to the four-byte mark, which is something that doesn;t bother x86 at all (and therefore doesn't affect the simulator): http://stackoverflow.com/questions/7788216/exc-bad-access-and-char-pointer-to-float-pointer-cast http://stackoverflow.com/questions/3243146/why-does-this-exc-bad-access-happen-with-long-long-and-not-with-int http://www.aleph1.co.uk/chapter-10-arm-structured-alignment-faq ...which seems like a bit of a showstopper for the Bank code included in iminiB3D, which doesn't appear to make any provision for alignment at all. I got it to work correctly with a simple modification to PeekFloat: float Bank::PeekFloat(int offset){
if(offset>=0 && offset<size-3){
float f; char * fb = (char *)&f;
fb[0] = buffer[offset];
fb[1] = buffer[offset + 1];
fb[2] = buffer[offset + 2];
fb[3] = buffer[offset + 3];
return f;
//return *(reinterpret_cast<float*>(&buffer[offset]));
}
return 0;
}...i.e. manually grab the four bytes of the float and put them in a slot we know to be aligned, before trying to access the data as a float. (Untidy, I know, but works for the moment.) Surely this can't be the right way to address this problem? Am I really the only person to have tried to load a .b3d file on this combination of platforms? Does this issue affect the iPhone? Or, more likely, am I missing something incredibly obvious (bear in mind that I am, after all, a bit of an idiot)? (Setup: iPad 2, iOS 5, Snow Leopard, old-model Mac mini.) Last edited 2011 |
| ||
| I've been using snow leopard and started on a mini a while ago for its Dev. My devices are all running iOS 5 now including the iPad 2. I have not noticed this problem however I don't tend to use a lot of meshes (been doing a lot of procedural stuff). Is it just certain meshes that cause this, or any mesh? ( if I dig up the zombie test and fire it off should I notice this or is it just a mesh you exported from something, if so what was it exported from/through?). How is your project built? Straight from the base project file or did you make your own project (possibly linker flags or something else affecting it on a different level...) |
| ||
| http://developer.android.com/guide/developing/tools/zipalign.html DUH-- sorry i see you're on iOS Last edited 2011 |
| ||
| if I dig up the zombie test and fire it off should I notice this Yes. I first worked out what it was in my own project, but it affects the out-of-the-box iminiB3D demo as well. I assume it affects any files that have float data aligned to something other than a four-byte boundary. My own models, and as far as I know, the zombie, were made with PaceMaker. |
| ||
| Yes, this is an issue that has recently cropped up, I think since LLVM has replaced GCC. I've only noticed it myself in the past few days, when attempting to recompile my own game. I'll attempt to fix it, but in the meantime, you might want to try using the LoadAnimB3DFile function instead of LoadAnimB3D (the former uses direct file access rather than loading the file into a bank first). This seems to work fine on all my devices, although I've heard it may not work on an iPad 2 - would you be able to test for me please Yasha? |
| ||
| In a very quick test, LoadAnimB3DFile worked fine in my own project (I managed to completely miss that that command existed until you mentioned it!), but interestingly didn't load the zombie when I tried swapping the line out in the bundled example. The app didn't fail: there just wasn't any zombie on screen. This was the case for both the simulator and the real device. I will try again later, and see if I can work out why the mesh wasn't displayed in the zombie demo. Last edited 2011 |
   |