https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=694

S Roderick <kiwi [dot] net [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution| |WORKSFORME
Status|NEW |RESOLVED

--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2009-10-27 15:32:58 ---
I closed this. We had a lot of trouble for a while, and lately everything has
been fine. I'm not sure what the final resolution was .... sorry. My only guess
is that in going away from Orocos versioned releases, to using our own git repo
tracking the Orocos repo's, this problem was solved on the mainline at some
point.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=694

--- Comment #2 from Peter Soetens <peter [..] ...> 2009-10-27 12:36:34 ---
(In reply to comment #1)
> Created an attachment (id=487)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=487)
> gdb backtraces for server crash
>
> Same behaviour with or without name server running. Name service is running on
> local machine.
>
> Same behaviour with or without "-ORBInitRef" option provided to executable.
>
> The server is not running in the deployer, but is manually starting two
> components and then attempting to create a controlTaskServer on one of the
> components.

Any status update here ? How did you work around it ? The backtrace is not that
useful if you didn't compile the RTT with CMAKE_BUILD_TYPE=Debug

Peter

On Aug 11, 2009, at 11:04 , S Roderick wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=694
>
> Summary: v1.8.4: Exceptions with omniORB on Mac
> Product: RTT
> Version: rtt-trunk
> Platform: All
> OS/Version: Mac OS X
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Corba
> AssignedTo: orocos-dev [..] ...
> ReportedBy: kiwi [dot] net [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> RTT v1.8.4 and omniORB v4.1.3 installed via Macports into Mac OS X
> 10.5.8.
>
> Getting multiple crash types.
>
> 1) crash on bringing up a server with two components in it
> 2) crash on exit of client that only has proxies to connect to above
> server
>
> Both work fine in ACE/TAO on the same machine (installed from
> source, v5.6.6)
>
> See attached logs.

2) solved. The exception was

terminate called after throwing an instance of 'omni_thread_fatal'

There was one exit path from our code that did not call

RTT::Corba::ControlTaskServer::ShutdownOrb(true);

With ACE/TAO this works fine, but with omniORB v4.1.3 this causes an
exception (this might be new omniORB behaviour, as this code has been
around for a while). Note that calling

RTT::Corba::ControlTaskServer::DestroyOrb();

instead is not sufficient. That results in a lockup of the program as
everything is waiting for something else.

Still no idea on 1) ... investigation continuing ...

HTH
Stephen

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=694

--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2009-08-11 17:09:34 ---
Created an attachment (id=487)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=487)
gdb backtraces for server crash

Same behaviour with or without name server running. Name service is running on
local machine.

Same behaviour with or without "-ORBInitRef" option provided to executable.

The server is not running in the deployer, but is manually starting two
components and then attempting to create a controlTaskServer on one of the
components.