flatbuffers C++ segmentation fault

[ashk-on]

auto rbPstart = (const unsigned char *)message_rcv.data();
 auto verifier = flatbuffers::Verifier(rbPstart,message_rcv.size());
auto bufOK = grl::flatbuffer::VerifyKUKAiiwaStatesBuffer(verifier);

if (bufOk){

auto fbKUKAiiwaStates = flatbuffer::GetKUKAiiwaStates(rbPstart);
auto force = fbKUKAiiwaStates->states()->Get(0)->monitorState()->CartesianWrench()->force();
double z = force.z();
std::cout << "received force:" << z << "\n";

}

This is on the c++ side after you receive the msg with zmq... the last statement(cout) causes segmentation fault. However I reopen the flatbuffer in the java side to check if the numbers are actually there, and they are really there! also the buffer size is the same before sending and after receiving... the verification also looks good.. but don't know why the values are not inside in C++ side!

[ahundt]

Hmm that is a bit puzzling. And code that receives a dummy test in a soul at way works? Have you tried stepping through in a debugger to look at the data?

On Tuesday, June 28, 2016, Ashkan372 notifications@github.com wrote:

auto rbPstart = (const unsigned char *)message_rcv.data(); auto verifier = flatbuffers::Verifier(rbPstart,message_rcv.size()); auto bufOK = grl::flatbuffer::VerifyKUKAiiwaStatesBuffer(verifier);

if (bufOk){

auto fbKUKAiiwaStates = flatbuffer::GetKUKAiiwaStates(rbPstart); auto force = fbKUKAiiwaStates->states()->Get(0)->monitorState()->CartesianWrench()->force(); double z = force.z(); std::cout << "received force:" << z << "\n";

}

This is on the c++ side after you receive the msg with zmq... the last statement(cout) causes segmentation fault. However I reopen the flatbuffer in the java side to check if the numbers are actually there, and they are really there! also the buffer size is the same before sending and after receiving... the verification also looks good.. but don't know why the values are not inside in C++ side!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ahundt/grl/issues/102, or mute the thread https://github.com/notifications/unsubscribe/AADZwJm1C9zoqPmOGkGhbLmp7ocH6T04ks5qQapegaJpZM4JAoGn .

Cheers! Andrew Hundt

Ph.D. Student Johns Hopkins University

[ashk-on]

No.. but I assume it is NULL..

[ahundt]

Okay well I can't really see much from the code that's there and can't test since I won't have access to a robot again until the end of August. I suggest writing a small bit of test code. Also, you could submit a pull request for me to look at and I'll try to help where I can!

On Wednesday, June 29, 2016, Ashkan372 notifications@github.com wrote:

No.. but I assume it is NULL..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ahundt/grl/issues/102#issuecomment-229363501, or mute the thread https://github.com/notifications/unsubscribe/AADZwD4EcDn2J8Co-xgbMHZ2Flof40HFks5qQnmogaJpZM4JAoGn .

Cheers! Andrew Hundt

[ashk-on]

Hi.. I checked in debugger.. and it is a random number like 2.230892394083e-317... although I had put 2.0 in this variable in flatbuffer... The strange thing is that the verifier works... but seems that the buffer contains junk... or something wrong with deserilization

[ashk-on]

Hey Andrew can you please help me debug how to decompose flatbuffers and read the data.

Can you please have a look on the way how I receive the data till the way I try to decompose the recv flatbuffer. Relevant code is

https://github.com/Ashkan372/grl/blob/master/include/grl/kuka/KukaJAVAdriver.hpp#L417-L462

Thanks a lot.

[ashk-on]

There was a minor problem on Java side, this C++ code was fine.