Hey,
swapping context makes no sense since context is for client - client generates
whatever context it wants and vpp just copies it from request to response, so
that client can match response with request. So there is no reason for client
to swap it when sending the message and then swap it back when receiving the
message. On the other hand, message ID is always in network byte order and thus
might need to be swapped.
Do you have or could you produce a piece of code which reproduces the issue,
please?
Thanks,
Klement
> On 28 May 2020, at 19:14, pashinho1...@gmail.com wrote:
>
> 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_pfcp_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_pfcp_add,
> vapi_msg_sample_plugin_pfcp_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_pfcp_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 (#16560): https://lists.fd.io/g/vpp-dev/message/16560
Mute This Topic: https://lists.fd.io/mt/74526467/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Mute #vapi: https://lists.fd.io/mk?hashtag=vapi&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
