Re: [ros-users] Debuggin ROS_COMM deserializer

Forside
Vedhæftede filer:
Indlæg som e-mail
+ (text/plain)
+ (text/html)
+ image001.gif (image/gif)
+ image002.png (image/png)
Slet denne besked
Besvar denne besked
Skribent: User discussions
Dato:  
Til: ros-users
Nye-emner: [ros-users] Importing libros in an IDE: possible?
Emne: Re: [ros-users] Debuggin ROS_COMM deserializer
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
>
> 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@tiscali.it>My linkedin profile
<http://it.linkedin.com/in/embeddedesign/en>

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