Jump to content
  • Advertisement
Sign in to follow this  
lawnjelly

SIGBUS illegal alignment

Recommended Posts

It comes that time again when I try and get my PC build working on Android via Android Studio. All was going swimmingly, it ran in the emulator fine, but on my first actual test device (Google Nexus 7 2012 tablet (32 bit ARM Cortex-A9, ARM v7A architecture)) I was getting a 'SIGBUS illegal alignment' crash.

My little research has indicated that while x86 is fine with loading 16 / 32 / 64 bit values from any byte address in memory, the earlier ARM chips may need data to be aligned to the data size. This isn't a massive problem, and I see the reason for it (probably faster, like SIMD aligned loads, and simpler for the CPU). I probably have quite a few of these, particular in my own byte packed file formats. I can adjust the exporter / formats so that they are using the required alignment.

Just to confirm, if anyone knows this, is it all 16 / 32 / 64 bit accesses that need to be data size aligned on early android devices? Or e.g. just 64 bit size access? 

And is there any easy way to get the compiler to spit out some kind of useful information as to the alignment of each member of a struct / class, so I can quickly pin down the culprits?

The ARM docs (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html) suggest another alternative is using a __packed qualifier. Anyone used this, is this practical?

Share this post


Link to post
Share on other sites
Advertisement

The X86 family incurs a penalty for doing it, and only the really old types support it. The 64-bit and larger data types typically require proper alignment. 

4 hours ago, lawnjelly said:

And is there any easy way to get the compiler to spit out some kind of useful information as to the alignment of each member of a struct / class, so I can quickly pin down the culprits?

C++ is supposed to properly align the values for types supported by the compiler.

For tracking it down, usually this comes from improper casts. A common source of those casts is serialization.  It can also happen anywhere else you perform unsafe casts, like a reinterpret_cast to convert from one type to another that has stricter alignment requirements.

When loading values from disk or network you cannot blindly cast to the right data type or data structure. You need to get the address of a proper variable, then copy the bytes directly into that object.  Usually that is done with bitwise manipulations or memcpy(). 

Once the data is loaded into properly aligned values, C++ should manipulate the data exactly as expected.

5 hours ago, lawnjelly said:

another alternative is using a __packed qualifier. Anyone used this, is this practical?

It adds a performance penalty (if it works at all on the compiler). The compiler adds additional code to ensure the value is suitably aligned, sometimes using temporary objects for member access.

Share this post


Link to post
Share on other sites

It was from serialization .. I use several file formats which are directly loaded into memory in place, then pointers fixed up, all with 1 byte packing. I had been lazy as some of the structures the alignment was not very neat and tidy throwing it off by a byte or short (thinking I'd finalize it later, and the processor would cope with it, albeit more slowly).

In the end it was simple to fix by adding a dummy short spacer in one of the structs. I'm not sure exactly what was triggering the SIGBUS fault, I'll have another look tomorrow, for future reference.

Interesting because none of the other structures caused the problem, despite some having dodgy alignment themselves.. but maybe I was using them differently (copying the data rather than using in place). I've also not had the problem on any earlier builds, but maybe my previous structs were better aligned.

Also shows the important of trying on the hardware rather than the just the emulator! :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!