VxWorks 6.9 with RTI ME 2.2.3 Issue

6 posts / 0 new
Last post
Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66
VxWorks 6.9 with RTI ME 2.2.3 Issue

Hi,

I used a simple Helloworld code from Tron in post "Finalize/Cleaning RTI DDS" in a RTP.
When launching it, process is stucked at DDS_DomainParticipantFactory_delete_participant().

I had the issue also in some case with a Kernel Execution.

If someone from RTI could try to reproduce the problem.
I have attached the code. In fact in code, goto done; has to be removed, otherwise RTP is killed and no issue is seen.

Regards,

Rodolf

AttachmentSize
File helloWorld.cpp6.94 KB
Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

It is even more simple to reproduce the problem with a RTP:

1/ Create Participant:

struct DDS_DomainParticipantQos dp_qos = DDS_DomainParticipantQos_INITIALIZER;

DDS_DomainParticipantFactory* factory = DDS_DomainParticipantFactory_get_instance();

participant = DDS_DomainParticipantFactory_create_participant(factory, 0, &dp_qos, NULL, DDS_STATUS_MASK_NONE);

2/ Delete Participant:

retcode = DDS_DomainParticipant_delete_contained_entities(participant);

retcode = DDS_DomainParticipantFactory_delete_participant(factory, participant);

Here we are stucked in this function.

Regards,

Rodolf

PS: Is it possibly linked to this post ?
http://community.rti.com/kb/what-does-deadlock-error-message-mean
O
r this one ?
http://community.rti.com/kb/why-does-my-application-hang-windows-when-deleting-participant but the problem occurs on VxWorks

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

I have changed source code to make the semTake not infinite.
In this case, only thread udp_rx_mc is not killed properly.

 

if (!NETIO_BindResolver_release_addresses(

participant->bind_resolver,
(struct REDA_StringSeq*)&participant->qos.transports.enabled_transports,NETIO_ROUTEKIND_USER,
(struct NETIO_AddressSeq*)&participant->builtin_data.default_unicast_locators))

{ DDSC_Log_release_user_uc( OSAPI_LOGKIND_ERROR);goto done; }

Offline
Last seen: 3 years 1 week ago
Joined: 01/17/2013
Posts: 13

Hi Rodolf,

Changing the semTake to a finite timeout is not the correct solution. Technically, it is not that the thread is not killed properly (threads are exited cleanly), the problem is that the multi-cast thread is not waking up. It is woken up by sending a message to itself, however the message is apparently not being received. What does the routing table look like on your vxworks board? I see the same behavior when multi-cast is not in the routing table. 

Try this:

In the vxworks route table:

route add  -netmask 224.0.0.0 224.0.0.0  <ip address of board>

In your application:
 

registry = DDS_DomainParticipantFactory_get_registry(factory);

if (!RT_Registry_unregister(registry, "_udp", NULL, NULL))
{
printf("failed to unregister udp\n");
goto done;
}

udp_property->multicast_interface = REDA_String_dup("lo0");

if (!RT_Registry_register(registry, "_udp",
UDP_InterfaceFactory_get_interface(),
(struct RT_ComponentFactoryProperty*)udp_property, NULL))
{
printf("failed to register udp\n");
goto done;
}

/ * Create & delete participant */

regards,

tron

 

 

 

 

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Hi,

I tried to add the route but it does not change the behaviour.

-> cmd route show

INET route table - vr: 0, table: 254
Destination                     Gateway                       Flags    Use   If    Metric
localhost                         localhost                           UH       0     lo0    0   
192.168.1.0/24                am335X_IDK                    UC       0     cpsw0  0   
am335X_IDK                   am335X_IDK                    UH       0     lo0    0   
224.0.0.0/3                      am335X_IDK                    UGS      0     lo0    0   
239.255.0.1:239.255.0.1 am335X_IDK                    UGS      0     lo0    0

I added also 239.255.0.1 as it is the default multicast @

What i can see, is that if the RTP has a priority lower than osapi_time thread (100) then it is OK, otherwise it is KO, waiting for something.
I could set the priority for udp threads but not for timer. I didn't found a way to set it.

Do you think that if i disable multicast, it will work ?
 

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Hi again,

to confirm that disable of multicast is making the issue solved.
As Participant QoS of RTI ME 2.2.3 has not the "multicast_enable" flag, i added deny of all 2**.***.***.***:

/* For unallowed interface(s) */
REDA_StringSeq_set_maximum(&udp_property->deny_interface,1);
REDA_StringSeq_set_length(&udp_property->deny_interface,1);
*REDA_StringSeq_get_reference(&udp_property->deny_interface,0) = "2*";

So for now on OK (all my participant are known and not in multicast, but if i want to use multicast, how can i do (solution above with add route not working) ?

Regards,

Rodolf