eboasson
commented
3 years ago I'd say this:
[state_estimation_node_exe-1] 1608317348.993236 [1] state_esti: ddsi_udp_create_conn: set IP_MULTICAST_IF failed: Bad Parameteris the weird bit: then the DDS domain doesn't start, the participant can't be created, nor can the node be created, &c. So one would thing everything else is collateral damage. That error really means:
return ddsrt_setsockopt (sock, IPPROTO_IP, IP_MULTICAST_IF, gv->ownloc.address + 12, 4);failed, or really
if (setsockopt(sock, level, optname, optval, optlen) == -1) {
goto err_setsockopt;
}Unfortunately, many errors get mapped to BAD_PARAMETER, so we don't know exactly what it is. However, sock must be ok or it wouldn't have made it to this point. So it is most likely that the kernel is unhappy with the address.
There are some things that should be fairly simple to do and that ought to provide a bit more information:
- Getting a trace from Cyclone should tell us what interfaces it thinks exist, and then one can infer the parameters;
- Run it under
straceto trace the inputs and outputs of the networking related system calls; - We could patch Cyclone to print the details (that might be easier than trying to catch it in a debugger).
I suspect that will show it always tries to set the multicast interface to use for outgoing packets, also when the socket isn't used for transmitting and even when the interface doesn't support multicast. Perhaps that is what the kernel doesn't like ... The good news is that the fix will be pretty straightforward if this is the case.
JWhitleyWork
jpace121
tfoote
Bug report
Required Info:
arm64rmw_cyclonedds_cppSteps to reproduce issue
Expected behavior
Tests pass.
Actual behavior
First test fails with the following error on Dashing:
And the following on Foxy:
Additional information
This has been tested both on
arm64-native hardware and usingarm64binary translation with QEMU. The test fails consistently in both Dashing and Foxy when using QEMU and occasionally onarm64-native hardware depending on the system load indicating that this is timing-dependent. Usingrmw_fastrtps_cpp, this failure does not occur. We have also only seen this error on this one test indicating it's a pretty corner-case scenario.For some context to aide in troubleshooting, this test intentionally provides the
state_estimation_nodewith conflicting parametersdata_driven: trueandoutput_frequency: 30.0. Using the free functiontime_between_publish_requestsinsrc/prediction/state_estimation_node/src/state_estimation_node.cppwith both of these parameters should throw astd::logic_erroron line 74 before any publishers/subscribers are created but after the node has been constructed/initialized. In Dashing, there is no indication that this exception is ever thrown but Foxy does show the output with the correct exception, only after the unexpectedrclerror.