• The system hangs doing rpc float types (armv6)
  • The system throws an illegal instruction (gumstix when serialising a geometry_msg).


  • Ros is attempting serialisation on an arm core.
  • The hardware floating point processor is being used.


  • The serialisation code is trying to access unaligned data, kernel doesn't like it.


You can instruct the kernel to set up an alignment trap so you can see when its occuring (you're not always lucky enough to get a signal from the kernel, so you can force it this way). To get a warning + signal

echo 5 > /proc/cpu/alignment

Other integer values trigger different levels of warning/signals/none.


  • Doesn't occur when using soft-float on a gumstix.
  • Open ticket re two locations where the problem occurs here.


This is a nice page discussing some of the issues on gumstix. Pertinent comment at the bottom (exactly valid or not?):

> Thanks for the input. After reading that I tend to agree that the code I > am using should be fixed to not try and access unaligned data. In fact I > have done this already with a bunch of memcpy's to make it run correctly.

Yeah - that sounds like the right way (read - most portable).

> The actual place where it is being used is in a network protocol reader > where there is a binary stream which gets copied into a memory buffer and > then it contains floats, ints, doubles, etc. referring to different bits > of data. It depends on where in the buffer the stream happens to be as to > whether there will be an alignment issue or not.

Yeah - so copying the data using mempcy from the unaligned buffer into an aligned buffer is the best way of dealing with this type of data.

Wiki: eros/alignment (last edited 2010-11-22 23:30:30 by DanielStonier)