[Edited Message Follows]
Hi all,
So, the problem is encountered with my C++ client when receiving a reply. The
strange thing is that this happens only with a specific type of api
request-reply.
Follows the segfault stack trace:
>
> Thread 1 "sample_plugin_client" hit Breakpoint 1,
> vapi_type_msg_header1_t_ntoh (h=0x0)
> at /usr/include/vapi/vapi_internal.h:63
> 63 h->_vl_msg_id = be16toh (h->_vl_msg_id);
> (gdb) bt
> #0 vapi_type_msg_header1_t_ntoh (h=0x0) at
> /usr/include/vapi/vapi_internal.h:63
> #1 0x0000000000406bff in vapi_msg_sample_plugin_session_add_reply_ntoh
> (msg=0x0) at /usr/include/vapi/sample_plugin.api.vapi.h:1215
> #2 0x0000000000419869 in
> vapi::vapi_swap_to_host<vapi_msg_sample_plugin_session_add_reply>
> (msg=0x0)
> at /usr/include/vapi/sample_plugin.api.vapi.hpp:260
> #3 0x0000000000419ad3 in
> vapi::Msg<vapi_msg_sample_plugin_session_add_reply>::assign_response
> (this=0x7fffffffe1b8,
> resp_id=49, shm_data=0x0) at /usr/include/vapi/vapi.hpp:614
> #4 0x0000000000419797 in
> vapi::Request<vapi_msg_sample_plugin_session_add,
> vapi_msg_sample_plugin_session_add_reply>::assign_response (
> this=0x7fffffffe170, id=49, shm_data=0x0) at
> /usr/include/vapi/vapi.hpp:684
> #5 0x0000000000410b1b in vapi::Connection::dispatch (this=0x7fffffffe2c0,
> limit=0x7fffffffe170, time=5)
> at /usr/include/vapi/vapi.hpp:289
> #6 0x0000000000410d9a in vapi::Connection::dispatch (this=0x7fffffffe2c0,
> limit=...)
> at /usr/include/vapi/vapi.hpp:324
> #7 0x0000000000410ddc in vapi::Connection::wait_for_response
> (this=0x7fffffffe2c0, req=...)
> at /usr/include/vapi/vapi.hpp:340
> #8 0x000000000040ba58 in sample_plugin_session_add (vpp_conn=...,
> msg_pload=...)
> at
> /root/tmp/vpp/src/plugins/sample_plugin/rubbish/client/src/sample_plugin_client.cpp:213
>
> #9 0x000000000040c485 in main () at
> /root/tmp/vpp/src/plugins/sample_plugin/rubbish/client/src/sample_plugin_client.cpp:388
>
Here's the kaboom " h->_vl_msg_id = be16toh (h->_vl_msg_id)", where 'h' is
NULL, yikes :O.
I traced the root cause in the 'vapi::Connection::dispatch()' method,
specifically here:
>
>
> u32 context = *reinterpret_cast<u32 *>((static_cast<u8 *> (shm_data) +
> vapi_get_context_offset (id))); // context' here is 218103808 in my case,
> for example
> const auto x = requests.front();
> matching_req = x;
> if (context == x->context) // while 'x->context' here is 13, i.e.
> htonl(13) is 218103808 (endianness inconsistency), so this branch here is
> not taken
> {
> std::tie (rv, break_dispatch) = x->assign_response (id, shm_data);
> }
> else // this one is taken, i.e. by passing 'nullptr' and subsequently
> being dereferenced ==> BOOM!
> {
> std::tie (rv, break_dispatch) = x->assign_response (id, nullptr);
> }
Also, I see REPLY_MACRO doing:
>
> rmp->_vl_msg_id = htons(REPLY_MSG_ID_BASE + VL_API_blablabla_REPLY);
> rmp->context = mp->context;
So '_vl_msg_id' gets network byte order, but not so with 'context', why's that?
Does this have something to do with the client's resulting segfault?
Oh, and I'm on top of the latest 'stable/2005'.
Thank you
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16559): https://lists.fd.io/g/vpp-dev/message/16559
Mute This Topic: https://lists.fd.io/mt/74526467/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
