x86 and x64 have no problems with unaligned read/write as far as I know -- which is why this hasn't come up.  Can you open a ticket and continue this discussion there?  It should be fairly easy to do some conditional changes based on CPU type.<div>

<br></div><div>Josh<br><br><div class="gmail_quote">On Mon, Jul 12, 2010 at 5:38 PM, Daniel Stonier <span dir="ltr"><<a href="mailto:d.stonier@gmail.com">d.stonier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><br></div><div>This seems to be a bit of problem code with regards to the alignment issues:<br></div><div><br></div><div>roscpp/src/libros/service_server_link.cpp</div><div><br></div><div>*****************************************************************************************</div>


<div><br></div><div>void ServiceServerLink::onResponseOkAndLength(const ConnectionPtr& conn, const boost::shared_array<uint8_t>& buffer, uint32_t size, bool success)<br>{<br>  ROS_ASSERT(conn == connection_);<br>


  ROS_ASSERT(size == 5);<br><br>  if (!success)<br>    return;<br><br>  uint8_t ok = buffer[0];<br>  uint32_t len = *((uint32_t*)(buffer.get() + 1));<br><br></div><div>*****************************************************************************************</div>


<div><br></div><div>That last line is where the signal is caught. I think the problem is, the arm core reads the uint32 values only at alignmed 4 byte boundaries - but that +1 generally shifts it off the 4 byte boundary and causes the signal.</div>


<div><br></div><div>Do intel machines even have an alignment trap like this arm core does? I noticed my machine does not have /proc/cpu/alignment.</div><div><br></div><div>Sorry, don't have a potential fix for it as I'm not familiar with this section of code yet.</div>


<div><br></div><div>More to come,</div><div>Regards,</div><div>Daniel.</div><div><div></div><div class="h5"><div><br></div><div><br></div><div class="gmail_quote">On 12 July 2010 19:04, Daniel Stonier <span dir="ltr"><<a href="mailto:d.stonier@gmail.com" target="_blank">d.stonier@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div>On 12 July 2010 17:24, René Wagner <span dir="ltr"><<a href="mailto:rene.wagner@dfki.de" target="_blank">rene.wagner@dfki.de</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, 2010-07-09 at 10:45 +0900, Daniel Stonier wrote:<br>
> - Patched (using the memcpy's rather than the reinterprets in the<br>
> SERIALIZER macro).<br>
> - In signal+warn mode (echo 5 > /proc/cpu/alignment)<br>
>   - (float64&int32) client gives a bus error and kernel outputs an<br>
> alignment trap message, but servers are fine<br>
> - In default mode (echo 0 > /proc/cpu/alignment)<br>
>   - (float64&int32) client and server function without hanging like before<br>
><br>
> So...its working, but is this the right fix?<br>
<br>
</div>You probably want to check where the unaligned memory access is<br>
happening. Can you run your float_client from within gdb? This should<br>
allow you to get a backtrace once the kernel has sent the signal (bus<br>
error) from the alignment trap.<br>
<br>
Cheers,<br>
<br>
Rene<br>
<font color="#888888"><br></font></blockquote></div><div>Getting some more meaningful backtraces now - catch bus errors for both the float64's and the int32's in some cases, some with, some without that memcopy patch above. I'll put together some results when I get back to work in the morning.</div>



<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888">-<br>
</font><div><div><div>------------------------------------------------------------<br>
Dipl.-Inf. René Wagner                     Junior Researcher<br>
DFKI Bremen                           Enrique-Schmidt-Str. 5<br>
Safe and Secure Cognitive Systems             D-28359 Bremen<br>
<br>
Phone: (+49) 421-218-64224       Fax: (+49) 421-218-98-64224<br>
Web: <a href="http://www.informatik.uni-bremen.de/agebv/en/ReneWagner" target="_blank">http://www.informatik.uni-bremen.de/agebv/en/ReneWagner</a><br>
--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --<br>
Deutsches Forschungszentrum für Künstliche Intelligenz  GmbH<br>
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern<br>
<br>
Geschäftsführung:<br>
   Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)<br>
                                          Dr. Walter Olthoff<br>
Vorsitzender des Aufsichtsrats:<br>
                                Prof. Dr. h.c. Hans A. Aukes<br>
Amtsgericht Kaiserslautern                          HRB 2313<br>
------------------------------------------------------------<br>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></div></blockquote></div><br><br clear="all"><br>-- <br><div><div>Phone : +82-10-5400-3296 (010-5400-3296)<br>Home: <a href="http://snorriheim.dnsdojo.com/" target="_blank">http://snorriheim.dnsdojo.com/</a><br>


Yujin Robot: <a href="http://www.yujinrobot.com/" target="_blank">http://www.yujinrobot.com/</a><br>
Embedded Control Libraries: <a href="http://snorriheim.dnsdojo.com/redmine/wiki/ecl" target="_blank">http://snorriheim.dnsdojo.com/redmine/wiki/ecl</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Phone : +82-10-5400-3296 (010-5400-3296)<br>Home: <a href="http://snorriheim.dnsdojo.com/" target="_blank">http://snorriheim.dnsdojo.com/</a><br>Yujin Robot: <a href="http://www.yujinrobot.com/" target="_blank">http://www.yujinrobot.com/</a><br>


Embedded Control Libraries: <a href="http://snorriheim.dnsdojo.com/redmine/wiki/ecl" target="_blank">http://snorriheim.dnsdojo.com/redmine/wiki/ecl</a><br>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>