Re: [certi-dev] Unable to create RTI ambassador

[Eric Noulard]

2011/8/31 Jan-Patrick Osterloh <address@hidden>:
>> Is the XPlane/HLA plugin multithreaded ?
>
> Yes, we start an update thread in the reflectAttribute callbacks in
> order to fasten callback delivery. But up to the point where the
> exception occurs, the wrapper it is single threaded. I know that xplane
> is starting multiple threads at startup (I started xplane in gdb. I
> assume that in one of this threads the plugin is started (also it is
> stated in the xplane documentation, that long runs of the callbacks
> should be avoided, because this would slow down the framerate of xplane
> too. Threfore I assumed that the plugin runs in the same thread as xplane.

Sure and whatever the situation the only problem would be to have several thread
calling libRTI I assume that currently even if XPlane is multithreaded libRTI is
only called from a single thread.

>> Currently libRTI is not thread-safe so that you should serialize the
>> call to libRTI
>> from a possible multithreaded app.
>
> We added semaphores in our multi-threaded parts. Our CASCaS Federate is
> multi-threaded, and there it works well. But at the point of exception,
> no multi-threading should be active.

OK.
>> Could you try to setup
>>
>> RTI_EXCEPTION=X
>> and
>> CERTI_EXCEPTION=X in order to see if any exceptoin is raised before RTIA 
>> dies?
>>
>> You may try to monitor message exchange using:
>> RTIA_MSG=D
>> and
>> RTIG_MSG=D
>>
>> that way CERTI will trace the message (sent or received) between
>> Federate and RTIA (RTIA_MSG)
>> and RTIG and RTIA (RTIG_MSG).
>
> I set these, and I get the following now, when I start xplane:
>
> UN Socket(RecevoirUN) : : No error
> HLALOG - 1314800573.328 LibRTI::UnjoinedFederate -
> d:/home/patrick/eclipse/certi/certi/libCERTI/Exception.cc>
> CERTI::Exception [NetworkError - reason=Error while receiving UN message.
> libRTI: exception: NetworkError (read)
> UN Socket(EmettreUN) : : No error
> HLALOG - 1314800573.328 LibRTI::UnjoinedFederate -
> d:/home/patrick/eclipse/certi/certi/libCERTI/Exception.cc>
> CERTI::Exception [NetworkError - reason=Error while sending UN message.
> libRTI: exception: NetworkError (write)
> libRTI: Could not execute 'Close connexion' service (Network error).
> Service request ignored.
>
> ERROR: Unable to create RTI ambassador: 'libRTI: Network Read Error
> waiting RTI reply'

This output looks truncated and it looks as if RTIA has never started
(or is already dead) when libRTI tries to send a message to it.

Coud you add manual trace (using std::cout or std::cerr inside RTIA constructor
and destructor (see CERTI/RTIA/RTIA.cc file)
 in order to check whether if RTIA destructor is not called prematurely.

The fork/CreateProcess is done inside RTIambassador constructor:
CERTI/libRTI/RTIambassador.cc lines 167--348, you can add traces in
there as well.

You can try with the debugger but it's sometimes difficult to debug
multiple processes.

Are you sure that your RTIambassador object is not going out-of-scope?

I think that in our ugly XPlane plugin we had to put the federate object
(which contains the RTIambassador object instance) as a pointer in
global scope (of the DLL)
and create the object inside:
PLUGIN_API int XPluginStart(char* outName, char* outSig, char* outDesc)

>> Did you verify that all the federate which are trying to join the
>> federation have unique name?
>
> Yes, it is the only Federate that is connecting to the Federation. I've
> not yet tried to start others ;-)

ok.

>>> I checked the DLLs, but everything seems OK so far. I can only imagine
>>> that xplane is loading some DLLs that interfere with CERTI, but I have
>>> no idea how to check this... the dependency walker just shows that
>>> xplane.exe uses a subset of the DLLs that the wrapper uses, and these
>>> are the same. I tried to copy the CERTI dll's also to different
>>> locations (next to xplane.exe, as well as in the plugin directory next
>>> to my plugin, but it makes no difference. I'm running out of ideas. If I
>>> would know, which DLLs are missing/wrong etc, it would be helpful.
>> When you test your XPlane HLA connection are there any other federate
>> in the federation?
> No, I've got a "fresh", just started RTIG, without any other federates
> joined or trying to join.

When you setup RTIG_MSG=D in the console (or context) where the rtig is started
did you see whether if RTIG receives any message from RTIA?

I guess no message will be received but I need to be sure.

I'm pretty sure RTIA is dying prematurely but I cannot understand why...

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org