[ros-users] Debuggin ROS_COMM deserializer

[Claudio Carbone]

Ok so I modified two things

ros_comm/clients/cpp/roscpp/src/libros/connection.cpp line 365 added
printf("Message length is %d\n", msg_len);

ros_comm/clients/cpp/roscpp/src/libros/topic_manager.cpp
ros_comm/clients/cpp/roscpp/src/libros/subscription.cpp

changed
boost::shared_array<uint8_t> buffer = boost::shared_array<uint8_t>(new 
uint8_t[header_bytes.size()]);
into
boost::shared_array<uint8_t> buffer = boost::shared_array<uint8_t>(new 
uint8_t[4096/*header_bytes.size()*/]);


None of this made any difference, the core still reports
[ERROR] [1354188131.716632948]: Exception thrown when deserializing 
message of length [157] from [/listener]: Buffer Overrun

Only place I see my added printf is in the talker and listener of the 
node_example tutorial, but they are printed just once or twice at the 
beginning.
What happens is this
when the processes (listener and talker) are first started, a message 
length is printed and is of size 1193/1192.
Then a second printf is executed and this second time values are 143/175.

Now first of all I don't understand why the size changes.
Second I don't get why the listener declares a length inferior to the 
one of the talker.
Theoretically they should both allocate the same memory.
Unfortunately I can't get comparative results without recompiling roscpp 
on another platform...

Next thing I'll do is artifically augmenting the buffer length in 
connection.cpp
from
uint32_t msg_len = len + 4;
to
uint32_t msg_len = len + 54;


Claudio



On 29/11/12 12:01, Claudio Carbone wrote:
> Regarding endianness determination, I built this simple program 
> (thanks stackoverflow!)
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
>
> int is_big_endian(void)
> {
>     union {
>         uint32_t i;
>         char c[4];
>     } bint = {0x01020304};
>
>     return bint.c[0] == 1;
> }
>
> int isLittleEndian()
> {
>     short int number = 0x1;
>     char *numPtr = (char*)&number;
>     return (numPtr[0] == 1);
> }
> /*
>  *
>  */
> int main(int argc, char** argv) {
>
>     int result;
>     result = is_big_endian();
>     printf("First test, is Big Endian : %s\n",result ? "True" : "False");
>     //printf("Raw result: %d\n",result);
>
>     result = isLittleEndian();
>     printf("Second test, is Little Endian : %s\n",result ? "True" : 
> "False");
>     //printf("Raw result: %d\n",result);
>     return (EXIT_SUCCESS);
> }
>
> Both methods return little_endian on both my x86 and my ARM machines.
> So endianness shouldn't be the problem.
>
> I'm now recompiling roscpp with a few printfs where Cedric indicated 
> to see what's happening, but only on the ARM.
> On the x86 I have ROS installed from binaries and I'd rather not 
> recompile everything there too.
>
> Claudio
>
>
> On 28/11/12 22:26, Brian Gerkey wrote:
>> I also suspect that it's an endian mismatch, which I mentioned in 
>> answer to this question at ROS Answers:
>> http://answers.ros.org/question/49136/arm-buffer-overrun-debug-help/
>>
>> There I suggested changing the endianness of the embedded machine; 
>> I've never done it myself, but I think that ARM processors can 
>> usually be switched between big and little endian.  As Cedric has 
>> pointed out, making roscpp endian-aware would be better, but making 
>> all of your machine little-endian is a pragmatic workaround.
>>
>> Btw, if your ARM is running big-endian, then that's almost certainly 
>> the problem.  You should run a sample program to determine that 
>> machine's endianness (look around for an example).
>>
>>     brian.
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users


-- 

*Eng. Claudio Carbone
Embedded Systems Design*

P.IVA: 11688471009
tel: +393809017424
email: Send email
<mailto:cla_carbone at tiscali.it>My linkedin profile 
<http://it.linkedin.com/in/embeddedesign/en>

My Portfolio
My portfolio site <http://www.fusioncoredesign.it/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121129/1f92d92f/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2321 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121129/1f92d92f/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 11839 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121129/1f92d92f/attachment-0004.png>