FBX loader crash on ARM (ipod touch 4).

2013-08-03
2013-08-04
  • Couldn't find any way to open a bug ticket, so I'll report this here. Hopefully it'll get picked up. There's an unaligned access bug in the FBX loader which causes a crash on my iOS test device (an ipod touch 4gen), and I suspect most/all ARM processors.

    The line in question is FBXParser.cpp:374:
    return static_cast<float>(reinterpret_cast<const double>(data+1));
    And the exact exception reported by LLDB is:
    EXC_BAD_ACCESS (code=EXC_ARM_DA_ALIGN, address=0x53dfa95).

    I'm using the code from git, compiling it directly in my project (as it's an iOS thing and libraries are pretty much useless on that stupid platform), my git clone is quite recent, probably from mid-june, worst case end of may. I don't have the time right now to try with the latest head/tip/top whatever it's called in git. If I do at some point I'll post a followup.

     
    Last edit: John Tsiombikas 2013-08-03
    • I fixed it, attached a patch against the current git HEAD.

      Verified that it works now for my test case, successfully loaded and rendered an FBX object on the ipod touch.

       
      Attachments
  • Thanks! Will apply it.

    Didn't know ARM processors have problems with unaligned memory accesses. I'd expect this to break way more often. Do you really need to load intermediate file formats on the target device?

     
  • I was a bit surprised as well, because I knew that older ARM processors had strict aligned access requirements (I've been programming the gameboy advance for instance which has an ARM7TDMI and definitely does this), but I had also heard that new ARM processors allow unaligned access.

    It turns out it's a bit more complicated: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html
    according to this aligned accesses are allowed for some of the memory access opcodes on new ARM processors, so it depends on what the compiler emitted. It also says that if you must do unaligned accesses you must tell the compiler that this pointer will be used for unaligned accesses (which I'm not sure if/how it works with gcc, clang, etc).

    And about formats, yeah, a bit blunt as an approach, but it works. And the only drawback is maybe slightly slower load times, and hugely bloated source code. So it'll have to do until it proves problematic.