Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Crash on Android during binary FBX import #24

jdduke opened this Issue · 16 comments

Using any of the NDK flavors of gcc (4.4, 4.6 and 4.7) for Android, with both STLport and libstdc++, I get a crash in one of ParseTokenAsID or ParseTokenAsFloat during binary FBX import. Below is a typical crash dump.

I/DEBUG ( 124): signal 7 (SIGBUS), code 128 (?), fault addr 00000000
I/DEBUG ( 124): r0 5d59a4d8 r1 6200d7d0 r2 0000004c r3 624114fd
I/DEBUG ( 124): r4 5d5bcc38 r5 5d5b7640 r6 5d5b7678 r7 623263e8
I/DEBUG ( 124): r8 5d59a4d8 r9 623263f0 sl 00000000 fp 62326960
I/DEBUG ( 124): ip 0000004f sp 623262e8 lr 61f5176f pc 61f3a228 cpsr 00000030
I/DEBUG ( 124): d0 697463656e6e6f43 d1 636146656c616362
I/DEBUG ( 124): d2 5d59a4a85d59a46a d3 5d59a4d85d59a465
I/DEBUG ( 124): d4 5d59a3885d59a370 d5 5d59a3b85d59a3a0
I/DEBUG ( 124): d6 5d59a3e85d59a3d0 d7 5d59a4185d59a400
I/DEBUG ( 124): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 124): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 124): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 124): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 124): d16 415c9c3800000000 d17 7e37e43c8800759c
I/DEBUG ( 124): d18 0000000000000002 d19 0000000000000000
I/DEBUG ( 124): d20 0000000000000000 d21 00000000bca237c3
I/DEBUG ( 124): d22 3f800000bf7fffe0 d23 3f800000bf7aee42
I/DEBUG ( 124): d24 000000003b360b61 d25 0000000000000000
I/DEBUG ( 124): d26 bae72ae400000000 d27 0000000000000000
I/DEBUG ( 124): d28 0000000000000000 d29 00000000bca237c3
I/DEBUG ( 124): d30 3f800000bf7fffe0 d31 3f800000bf7aee42
I/DEBUG ( 124): scr 80000096
I/DEBUG ( 124):
I/DEBUG ( 124): backtrace:
I/DEBUG ( 124): #00 pc 0029e228 /data/app-lib// (Assimp::FBX::ParseTokenAsID(Assimp::FBX::Token const&)+139)
I/DEBUG ( 124): #1 pc 002b576b /data/app-lib/
/ (Assimp::FBX::Document::ReadConnections()+194)
I/DEBUG ( 124):
I/DEBUG ( 124): stack:
I/DEBUG ( 124): 623262a8 00000002
I/DEBUG ( 124): 623262ac 61f90c7c /data/app-lib// (std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator const&)+100)
I/DEBUG ( 124): 623262b0 5d5bcc44
I/DEBUG ( 124): 623262b4 61f91b88 /data/app-lib/
/ (char* std::string::_S_construct(char const, char const, std::allocator const&, std::forward_iterator_tag)+76)
I/DEBUG ( 124): 623262b8 00000000
I/DEBUG ( 124): 623262bc 623262f8
I/DEBUG ( 124): 623262c0 00000000
I/DEBUG ( 124): 623262c4 5d59a4a8
I/DEBUG ( 124): 623262c8 623263e8
I/DEBUG ( 124): 623262cc 61f91c20 /data/app-lib// (std::basic_string, std::allocator >::basic_string(char const, unsigned int, std::allocator const&)+28)
I/DEBUG ( 124): 623262d0 623262f8
I/DEBUG ( 124): 623262d4 61f3a0f5 /data/app-lib// (Assimp::FBX::ParseTokenAsString(Assimp::FBX::Token const&, char const&)+144)
I/DEBUG ( 124): 623262d8 c0000000
I/DEBUG ( 124): 623262dc 5d5bcc38
I/DEBUG ( 124): 623262e0 e3a070ad
I/DEBUG ( 124): 623262e4 ef9000ad
I/DEBUG ( 124): #00 623262e8 62326350
I/DEBUG ( 124): 623262ec 61f3a149 /data/app-lib// (Assimp::FBX::ParseTokenAsString(Assimp::FBX::Token const&)+32)
I/DEBUG ( 124): 623262f0 5d5bcc38
I/DEBUG ( 124): 623262f4 5d5b7640
I/DEBUG ( 124): 623262f8 5d5b7678
I/DEBUG ( 124): 623262fc 623263e
I/DEBUG ( 124): 62326300 623263ec
I/DEBUG ( 124): 62326304 623263f0
I/DEBUG ( 124): 62326308 00000000
I/DEBUG ( 124): 6232630c 61f5176f /data/app-lib/
/ (Assimp::FBX::Document::ReadConnections()+198)
I/DEBUG ( 124): 62326310 00000008
I/DEBUG ( 124): 62326314 5d5b76a8
I/DEBUG ( 124): 62326318 00000000
I/DEBUG ( 124): 6232631c 00000000
I/DEBUG ( 124): 62326320 5d5b7e28
I/DEBUG ( 124): 62326324 62086adc

@acgessler acgessler was assigned

I also can't import FBX with assimp on Android

I don't have the full stack trace but I have this error:
09-13 09:24:26.365 6053-6053/com.qualcomm.QCARSamples.FrameMarkers A/libc﹕ Fatal signal 7 (SIGBUS) at 0x746421ea (code=1), thread 6053 (es.FrameMarkers)

I think it may be related


Can we get the FBX file(s) you used so we can reproduce?


Any of the binary FBX files in our test data folder should trigger it.

@acgessler acgessler was unassigned by kimkulling
@kimkulling kimkulling self-assigned this

I'm interested in assimp releasing a new version of their software so I will try to push this oldest issues a bit.

Is there any news on this issue since the last comment?

Thanks in advance.


I've also ran into this issue as well. Any update?

I have assimp loading other formats such as .obj but it's failing on fbx.



same here with:

const struct aiScene* assimpScene = importer.ReadFileFromMemory((const void *) buffer,
aiProcess_Triangulate | aiProcess_GenSmoothNormals,



in FBXParser.cpp -> ParseTokenAsFloat

in android there is a sigbus because bad memory aligment, i've solved it with memcpy //commented parts are the previous ones

const char* data = t.begin();
if (data[0] != 'F' && data[0] != 'D') {
err_out = "failed to parse F(loat) or D(ouble), unexpected data type (binary)";
return 0.0f;

    if (data[0] == 'F') {
        ai_assert(t.end() - data == 5);
        // no byte swapping needed for ieee floats
        float returnFloat;
        memcpy(&returnFloat, data+1, sizeof(float));
        return returnFloat;//*reinterpret_cast<const float*>(data+1);
    else {
        ai_assert(t.end() - data == 9);
        // no byte swapping needed for ieee floats
        double returnFloat;
        memcpy(&returnFloat, data+1, sizeof(double));
        return (float) returnFloat;//static_cast<float>(*reinterpret_cast<const double*>(data+1));

Awesome finding.

I strongly suspect that other loaders are suspected of similar code as well ...


currently i've integrated assimp to my c++ opengl engine for android and ios, if i found any other issue i will post it

my patch is a little uggly but it was a hotfix, how you will integrate it in a cleaner way?


I think we'll go with memcpy.

reinterpret_cast breaks strict aliasing rules. The union trick is allowed by many compilers, but strictly speaking it is a violation of a rule that writing to an union with type A and directly thereafter reading with type B is undefined behaviour as well.

@acgessler acgessler closed this issue from a commit
@acgessler acgessler FBX: use memcpy() instead of reinterpret_cast or union to populate a …
…float from a blob, causing SIGBUS errors on Android due to memory alignment of the source blob not being a multiple of 4/8. This fixes #24.
@acgessler acgessler closed this in becd298

Thanks! Very glad to solve this. Re-open if the issue persists (I don't have the means of checking on Android right now ... )


I've noticed a number of other places in FBXParser.cpp where we reinterpret_cast doubles, uint64s, etc... Are they not also candidates for the memcpy workaround?


Frankly, yes, almost every reinterpret_cast in the entire library should be a candidate. I just saw there is plenty of them.

@acgessler acgessler reopened this

Any update? Still got crash if loading fbx files on Android.


You can use Clang's undefined sanitizer to debug this on desktop. It will shout at you whenever you do unaligned loads. GCC 5 should also have this feature. You might have to use Linux though, not sure what Clang windows status is.


I have also experienced this issue - binary fbx file can't be loaded on Android.
I have narrowed down the problem to buggy behavior of AndroidJNIIOSystem.

By using irrlicht and leveraging its filesystem interface, I have solved the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.