conflicted with other rpc tool such as xmlrpc/rcf on TX2(aarch64) platform

[cadaeb]

conflicted with other rpc tool such as xmlrpc/rcf on TX2(aarch64) platform

To Reproduce Choose nvidia TX2 platform

1. Add a rpc lib such as "RCF" in the same program and create a thread to build a TCPEndpoint such as follows: static RCF::RcfInit rcfInit; std::string networkInterface = "192.168.0.66"; int port = 50001;

// Start a TCP server, and expose DemoService. DemoService demoService; static RCF::RcfServer server( RCF::UdpEndpoint(networkInterface, port) ); server.bind(demoService); server.start();

2. Initilize IFM3d in another thread such as follows: std::string port_name; port_name = "192.168.0.69"; m_Camera = std::make_shared(port_name); m_FrameGrabber = std::make_shared(m_Camera); m_ImageBuffer = std::make_shared();

3. No matter whether grabbing the IFM frame, the program willl be dumpped with a gdb result as follows:

0x0000005555994f94 in void asio::detail::op_queue_access::next<asio::detail::task_io_service_operation, asio::detail::task_io_service_operation>(asio::detail::task_io_service_operation*&, asio::detail::task_io_service_operation*) ()
(gdb) bt
#0  0x0000005555994f94 in void asio::detail::op_queue_access::next<asio::detail::task_io_service_operation, asio::detail::task_io_service_operation>(asio::detail::task_io_service_operation*&, asio::detail::task_io_service_operation*) ()
#1  0x000000555596bca8 in asio::detail::op_queue<asio::detail::task_io_service_operation>::push(asio::detail::task_io_service_operation*) ()
#2  0x000000555595b880 in asio::detail::task_io_service::post_immediate_completion(asio::detail::task_io_service_operation*, bool) ()
#3  0x0000005555959f64 in asio::detail::epoll_reactor::start_op(int, int, asio::detail::epoll_reactor::descriptor_state*&, asio::detail::reactor_op*, bool, bool) ()
#4  0x000000555595e588 in asio::detail::reactive_socket_service_base::start_op(asio::detail::reactive_socket_service_base::base_implementation_type&, int, asio::detail::reactor_op*, bool, bool, bool) ()
#5  0x0000007fb17a2128 in  () at /usr/local/lib/libifm3d_framegrabber.so.0.20.0
#6  0x0000007fb17a2304 in  () at /usr/local/lib/libifm3d_framegrabber.so.0.20.0
#7  0x0000007fb17a265c in  () at /usr/local/lib/libifm3d_framegrabber.so.0.20.0

It will in a same case when I use a simple XMLRPC server. And I guess all these RPC tools may use same fundmetal boost lib where something unexcecpted happens.

I struggled to use static or shared linked lib and both failed .

[graugans]

Hey @cadaeb , thanks for the input. Do you see this issue only on the Nvidia TX2 or is it more related to the usage of the libraries itself? We have received some feedback that there seems to be an issue on the Xavier/Nano related to the latest L4T (JetPack) Release from Nvidia could you please be so kind and provide us with the version information:

• L4T (JetPack) version used
• RCF version used assuming you use this library.
• Have you compile RCF from source/use the one from the L4T OS or any third Party version
• ifm3d version
• Are you using ifm3d binaries or do you have build it from source

It will in a same case when I use a simple XMLRPC server. And I guess all these RPC tools may use same fundmetal boost lib where something unexcecpted happens.

What XMLRPC server are you using?

[cadaeb]

thanks for your replyment and I will supply more detailed information tommorrow according to your mail. BTW, one of my friend took a similar test on tx2 nano and succeed with no errors. I wonder whether the Master branch on GIT HUB is OK? I complid the source code of Master branch while my friend use version 0.82发自我的荣耀手机-------- 原始邮件 --------发件人： Christian Ege @.>日期： 2021年10月26日周二 晚上10:15收件人： ifm/ifm3d @.>抄送： cadaeb @.>, Mention @.>主 题： Re: [ifm/ifm3d] conflicted with other rpc tool such as xmlrpc/rcf on TX2(aarch64) platform (Issue #329) Hey @cadaeb , thanks for the input. Do you see this issue only on the Nvidia TX2 or is it more related to the usage of the libraries itself? We have received some feedback that there seems to be an issue on the Xavier/Nano related to the latest L4T (JetPack) Release from Nvidia could you please be so kind and provide us with the version information: L4T (JetPack) version usedRCF version used assuming you use this library.Have you compile RCF from source/use the one from the L4T OS or any third Party versionifm3d versionAre you using ifm3d binaries or do you have build it from source

It will in a same case when I use a simple XMLRPC server. And I guess all these RPC tools may use same fundmetal boost lib where something unexcecpted happens.

What XMLRPC server are you using?

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.

[cadaeb]

1. JetPack 4.3
2. RCF is built from source and its version is 3.2
3. Master branch of ifm3d
4. build ifm3d from source Furthermore, XMLRPC server I used is just the simpliest dome copied from open source, as follows:

class XmlRpcServer {

private: class MyTestMethod:public xmlrpc_c::method { public: MyTestMethod(){ this->_signature="A:ii"; this->_help="This method updates pos and reloc state"; }

    void execute(xmlrpc_c::paramList const& paramList, xmlrpc_c::value* const retval)
    {
          // XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    }
};

private: xmlrpc_c::registry addIntRegistry; xmlrpc_c::serverAbyss* AbyssServer; int port; int socket_fd;

public: void regester_xml_method(); int setupServer(); int setupSocket();

public: XmlRpcServer(int _port):port(_port),socket_fd(-1){} };

It should be pointed out that when I embed this XMLRPC server in a program with IFM3d driver, the program can run without dump, however other client can not connect the server successfully.

At 2021-10-26 22:15:12, "Christian Ege" @.***> wrote:

Hey @cadaeb , thanks for the input. Do you see this issue only on the Nvidia TX2 or is it more related to the usage of the libraries itself? We have received some feedback that there seems to be an issue on the Xavier/Nano related to the latest L4T (JetPack) Release from Nvidia could you please be so kind and provide us with the version information:

L4T (JetPack) version used RCF version used assuming you use this library. Have you compile RCF from source/use the one from the L4T OS or any third Party version ifm3d version Are you using ifm3d binaries or do you have build it from source

It will in a same case when I use a simple XMLRPC server. And I guess all these RPC tools may use same fundmetal boost lib where something unexcecpted happens.

What XMLRPC server are you using?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[inbangsa]

@cadaeb Thanks for the issue, I am able to reproduce segmentation fault on ubuntu 18.04 if an application linked RCF and ifm3d both.

Problem : Both ifm3d and RCF embedded asio header only lib and the issue is different version of asio in both the repos. ifm3d uses asio-1.16.0 and RCP lastest version ( 3.2.413) uses asio-1.10.6 and hence the issue when both are linked to one application.

Solution: provide same asio version to both libs. So I am providing a patch with base as ifm3d v-0.20.0 ( master) which provides option to set ASIO_DIR to provide different version of asio.

Process to resolve the issue :

• Check the asio version with RCF ( RCF-3.2.413 uses asio-1.10.6)
• Clone the same version of asio from asio repo
• clone the ifm3d and apply patch
• pass -DASIO_DIR= to the configure step of ifm3d (cmake -DCMAKE_INSTALL_PREFIX=/usr -DEXTERNAL_ASIO="asio-path" .. )
• build and install ifm3d

after above steps i am able to link and execute RFC example along with ifm3d linked to application.

Please let me know if these solves your issue, we are planning to provide this external asio_dir feature in future release.

[graugans]

@cadaeb and @inbangsa It looks like there is also a similar issue within Fast-DDS

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.