EXC_BAD_INSTRUCTION signal on iPhone 3G

[GoogleCodeExporter]

Running iPhoneDemo on an iPhone 3G with iOS 4.2 gets an EXC_BAD_INSTRUCTION 
signal while starting. 

The line where the signal occurs is:
line 292 in utStreams.cpp

utMemoryStream::utMemoryStream(int mode)
: m_buffer(0), m_pos(0), m_size(0), m_capacity(0), m_mode(mode)
{
}

I can run the same compiled app on an iPhone 3G

I modified all targets to only build armv6 but the problem persisted. I also 
added some gkLogMessage calls in gkBlendLoader::loadFile and 
gkBlendLoader::loadAndCatch, and it suddenly started running, although 
extremely slow (maybe that's to be expected in an iPhone 3G).

Debugging with gdb the instruction that fails is "ldr r3, [r3, #0]", where r3 
has the value 0xffffffff. So I guess the problem is the value in r3, but I have 
no idea how that value got there, or why it only happens in an iPhone 3G.

Original issue reported on code.google.com by max.mar...@gmail.com on 2 Feb 2011 at 1:21

[GoogleCodeExporter]

I think, this issue is possible caused by iPhone3 memory limitation.

Ogrekit runtime required roughly 76Mbytes for running on iOS simulator.
http://twitpic.com/43lbs5

but iPhone3 has 30MBytes free memroy for application. (iPhone3GS 100MBytes, 
iPhone4 210MBytes.)
http://www.recessionapps.com/Free_Memory.html

If you change the sample blend file to more smaller size file, you can reduce 
memory usage, but still not enough for iPhone3.

Sorry, I don't know how to fix it at the moment.

Original comment by harkon...@gmail.com on 25 Feb 2011 at 2:36

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I cannot dev for iphone (not even in an emulator) but I have a few idead from 
where the memmory is eaten. If you have some tools that can confirm it, it 
would be intersting to verrify.

- The executable binary size is huge. Maybe stripping doewn freeimage of 
unsuded codec, Ogre of all unused code and not inlining soem code can help here.

- Mesh vertex buffer format is overkill (AoS with 8 UV layers for all vertex). 
Moving to a more flexible SoA for vertex buffer would correct this (and also 
optimise cache use). I started simples akMesh/akSubMesh/akVertexBuffer classes 
in animkit that are more suited to the task. I also did something similar for 
the animationcurves (passed to a SoA and do not allocate bezier handles when 
not needed)

- Fragmentation, the loader allocate memory for the blender structure than 
structs for gamekit data and some others temporary data. Then most of the 
gamekit and temporary  data is "grown" using realloc. (For example a gkMesh 
redimension his vertexbuffer when addTriangle() is used and the array is not 
big enought.) I tried some test to correct this in the animkit demo blender 
loader which calculate the excat needed size and does only one allocaction (i 
did it for animations curves too).

Original comment by xavier.thomas.1980@gmail.com on 25 Feb 2011 at 3:48

• Added labels: ****
• Removed labels: ****