[ros-users] Ros on Arm Hanging

[Daniel Stonier]

Ok, opened: https://code.ros.org/trac/ros/ticket/2883

On 13 July 2010 09:42, Josh Faust <jfaust at willowgarage.com> wrote:

> 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.
>
> Josh
>
>
> On Mon, Jul 12, 2010 at 5:38 PM, Daniel Stonier <d.stonier at gmail.com>wrote:
>
>>
>> This seems to be a bit of problem code with regards to the alignment
>> issues:
>>
>> roscpp/src/libros/service_server_link.cpp
>>
>>
>> *****************************************************************************************
>>
>> void ServiceServerLink::onResponseOkAndLength(const ConnectionPtr& conn,
>> const boost::shared_array<uint8_t>& buffer, uint32_t size, bool success)
>> {
>> ROS_ASSERT(conn == connection_);
>> ROS_ASSERT(size == 5);
>>
>> if (!success)
>> return;
>>
>> uint8_t ok = buffer[0];
>> uint32_t len = *((uint32_t*)(buffer.get() + 1));
>>
>>
>> *****************************************************************************************
>>
>> 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.
>>
>> Do intel machines even have an alignment trap like this arm core does? I
>> noticed my machine does not have /proc/cpu/alignment.
>>
>> Sorry, don't have a potential fix for it as I'm not familiar with this
>> section of code yet.
>>
>> More to come,
>> Regards,
>> Daniel.
>>
>>
>> On 12 July 2010 19:04, Daniel Stonier <d.stonier at gmail.com> wrote:
>>
>>>
>>>
>>> On 12 July 2010 17:24, René Wagner <rene.wagner at dfki.de> wrote:
>>>
>>>> On Fri, 2010-07-09 at 10:45 +0900, Daniel Stonier wrote:
>>>> > - Patched (using the memcpy's rather than the reinterprets in the
>>>> > SERIALIZER macro).
>>>> > - In signal+warn mode (echo 5 > /proc/cpu/alignment)
>>>> >   - (float64&int32) client gives a bus error and kernel outputs an
>>>> > alignment trap message, but servers are fine
>>>> > - In default mode (echo 0 > /proc/cpu/alignment)
>>>> >   - (float64&int32) client and server function without hanging like
>>>> before
>>>> >
>>>> > So...its working, but is this the right fix?
>>>>
>>>> You probably want to check where the unaligned memory access is
>>>> happening. Can you run your float_client from within gdb? This should
>>>> allow you to get a backtrace once the kernel has sent the signal (bus
>>>> error) from the alignment trap.
>>>>
>>>> Cheers,
>>>>
>>>> Rene
>>>>
>>>> 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.
>>>
>>>
>>>
>>>
>>>> -
>>>> ------------------------------------------------------------
>>>> Dipl.-Inf. René Wagner                     Junior Researcher
>>>> DFKI Bremen                           Enrique-Schmidt-Str. 5
>>>> Safe and Secure Cognitive Systems             D-28359 Bremen
>>>>
>>>> Phone: (+49) 421-218-64224       Fax: (+49) 421-218-98-64224
>>>> Web: http://www.informatik.uni-bremen.de/agebv/en/ReneWagner
>>>> --- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>> Deutsches Forschungszentrum für Künstliche Intelligenz  GmbH
>>>> Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
>>>>
>>>> Geschäftsführung:
>>>>   Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>>>>                                          Dr. Walter Olthoff
>>>> Vorsitzender des Aufsichtsrats:
>>>>                                Prof. Dr. h.c. Hans A. Aukes
>>>> Amtsgericht Kaiserslautern                          HRB 2313
>>>> ------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>
>>>
>>>
>>> --
>>> Phone : +82-10-5400-3296 (010-5400-3296)
>>> Home: http://snorriheim.dnsdojo.com/
>>> Yujin Robot: http://www.yujinrobot.com/
>>> Embedded Control Libraries:
>>> http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>>>
>>
>>
>>
>> --
>> Phone : +82-10-5400-3296 (010-5400-3296)
>> Home: http://snorriheim.dnsdojo.com/
>> Yujin Robot: http://www.yujinrobot.com/
>> Embedded Control Libraries:
>> http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin Robot: http://www.yujinrobot.com/
Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100713/142d2ae3/attachment-0003.html>