2012/10/15 Mathieu Gautier <mathieu [dot] gautier [..] ...>

> Hi peter,
>
>
>
>>>>
>>>>
>>>>> The exception should have been a 'return false'. I fixed this on the
>>>>> master of RTT. So now you should be able to debug the error messages
>>>>> more consistently. The difference between Debian and Ubuntu might be
>>>>> due to subtle differences in how the boost::filesystem works across
>>>>> versions. Could you tell us the Debian and Ubuntu versions of Boost
>>>>> you're using ?
>>>>>
>>>>> I don't like it that the deployer went into exception state itself, so
>>>>> this might change before final release. In my opinion, the exception
>>>>> state is for catching exceptions in one of the *Hook functions of the
>>>>> component. Mathieu implemented this functionality in order to have
>>>>> consistent behavior when an operation throws.
>>>>>
>>>>
>>>>
>>>> Just a comment on the lack of feedback when an operation throw an
>>>> exception.
>>>>
>>>> To help debugging in such a case, we might want to add logging in
>>>> RStore::exec (BindStorage.hpp) inside the catch statement.
>>>> Besides, I think it may be useful to give back the exception message,
>>>> instead of the clumsy message ("Unable to complete the operation call.
>>>> The
>>>> called operation has thrown an exception"). The exception type is still
>>>> lost, since only a new runtime_error with the exception message is
>>>> thrown.
>>>> Some months ago, I made a patch that I have not submitted, where I
>>>> added a
>>>> std::string to RStore to store the exception message between exec()
>>>> where
>>>> the exception is caught and checkError() where the generic
>>>> runtime_error is
>>>> thrown. But, I fear that the instantiation of an object with an empty
>>>> std::string member might be detrimental to real-time application.
>>>>
>>>
>>> "Then don't throw".
>>>
>>> That's the answer we have for component writers which want real-time
>>> behavior.
>>> Once you throw *outside your interface*, we're taking over. That's
>>> what we agreed
>>>
>>
> Yes, I agree. What I don't know, is that adding a std::string object in
> RStore might be problematic in the general case when creating a RStore (see
> the attached patch.)
>
>
> on when this patch was discussed. I could defend logging, even if it's
>>> in the core
>>> of the real-time system, if the user gave up. So please post your patch
>>> that we
>>> can discuss this further.
>>>
>>
> I just modify the patch for the last revision of the master branch.
> There's two thing, the logging in Debug level and the "exception message
> forwarding".
>
>
>
>>> The component going to the X state is for me however going to far,
>>> it's an interface
>>> function which threw to the caller of that function, not a Hook
>>> function, for which
>>> the X state was invented. If you want to enter X as well (as a matter
>>> of announcing
>>> complete catastrophe to supervision), just call the this->exception()
>>> function
>>> in your interface function before returning/throwing.
>>>
>>
>> Hmm, I just reread the thread where we discussed all this and it was my
>> proposal
>> to make the TC go to the X state if an operation throws (to signal
>> that the component
>> did something erroneous) . After seeing it work once though, I already
>> disliked it.
>> I have a patch ready that removes that feature, but before we go yo-yo:
>> other's thoughts ?
>>
>
> I always was uncomfortable with this behavior, too. It's too drastic when
> dealing with a classic C++ library, since, in exception state we have no
> access to the triggered exception. I rather leave this up to the
> component's developpers, by dealing with the exception in the operation
> definition if needed.
>

I can't agree with you on that point...
When a user develops a component and do not take care of handling
exceptions raised by a third-party library, I think it is a good behavior
to have the component go in a "safe" exception state instead of just
staying alive or just crashing!

If you want to cleanly deal with exceptions, you can still catch them in
your component hooks or operations, so that they are not thrown to the RTT
layer!

Charles.

>
> --
> Mathieu
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

Hi,

>
> The exception should have been a 'return false'. I fixed this on the
> master of RTT. So now you should be able to debug the error messages
> more consistently. The difference between Debian and Ubuntu might be
> due to subtle differences in how the boost::filesystem works across
> versions. Could you tell us the Debian and Ubuntu versions of Boost
> you're using ?
>
> I don't like it that the deployer went into exception state itself, so
> this might change before final release. In my opinion, the exception
> state is for catching exceptions in one of the *Hook functions of the
> component. Mathieu implemented this functionality in order to have
> consistent behavior when an operation throws.

Just a comment on the lack of feedback when an operation throw an exception.

To help debugging in such a case, we might want to add logging in
RStore::exec (BindStorage.hpp) inside the catch statement.
Besides, I think it may be useful to give back the exception message,
instead of the clumsy message ("Unable to complete the operation call.
The called operation has thrown an exception"). The exception type is
still lost, since only a new runtime_error with the exception message is
thrown.
Some months ago, I made a patch that I have not submitted, where I added
a std::string to RStore to store the exception message between exec()
where the exception is caught and checkError() where the generic
runtime_error is thrown. But, I fear that the instantiation of an object
with an empty std::string member might be detrimental to real-time
application.

Regards,

On 10/12/2012 02:49 PM, Peter Soetens wrote:
> Hi Sagar,
>
> The exception should have been a 'return false'. I fixed this on the
> master of RTT. So now you should be able to debug the error messages
> more consistently. The difference between Debian and Ubuntu might be
> due to subtle differences in how the boost::filesystem works across
> versions.

Okay, if you are certain that there are no changes relevant to this
between the current master and the toolchain-2.5 branches..

> Could you tell us the Debian and Ubuntu versions of Boost
> you're using ?

On Debian wheezy: libboost_filesystem.so.1.49.0 from wheezy repos

On Ubuntu 10.04: libboost_filesystem.so.1.44.0 which was manually
compiled from the boost sources.

/Sagar

> I don't like it that the deployer went into exception state itself, so
> this might change before final release. In my opinion, the exception
> state is for catching exceptions in one of the *Hook functions of the
> component. Mathieu implemented this functionality in order to have
> consistent behavior when an operation throws.
>
> Peter
>
> On Fri, Oct 12, 2012 at 1:05 PM, Sagar Behere<sagar [dot] behere [..] ...> wrote:
>> On 10/12/2012 11:58 AM, Peter Soetens wrote:
>>>
>>> Hi Sagar,
>>>
>>> I noticed this once too and I think its related to the updates of the
>>> ComponentLoader...
>>
>>
>> This error does not seem to be deterministic. This sounds crazy, but I came
>> back from lunch, and tried the exact same thing again, and it did not throw
>> any exception.
>>
>> import("/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless")
>>
>> So I removed the 'wireless' from the path and the expected result would be
>> that it won't import anything
>>
>> import("/home/sagar/excludes/tmp/lib/orocos/gnulinux")
>>
>> At this point, it threw the exception.
>>
>> After doing this a couple of times, I tried with the initial command again
>>
>> import("/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless")
>>
>> This time, it threw the exception. So I restarted the deployer with
>>
>> $ deployer -ldebug
>>
>> and did the import(). It threw the exception, but the orocos.log file
>> doesn't seem to have any relevant information. It doesn't even mention that
>> an exception was thrown. The relevant snippet is
>>
>> -----
>> 0.076 [ Info ][Logger] Entering Task Deployer
>> 7.233 [ Info ][DeploymentComponent::import] Importing directory
>> /home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/ ...
>> 7.233 [ Debug ][DeploymentComponent::import] Scanning file
>> /home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/libwireless-gnulinux.so
>> ...Succesfully loaded wireless
>> 7.233 [ Info ][DeploymentComponent::import] Loaded component type
>> 'Wireless'
>> 7.233 [ Debug ][DeploymentComponent::import] Looking for plugins or
>> typekits in directory /home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/
>> ...
>> 7.233 [ Debug ][DeploymentComponent::import] No such directory:
>> "/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/types"
>> 7.233 [ Debug ][DeploymentComponent::import] No such directory:
>> "/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/plugins"
>> 7.233 [ Debug ][DeploymentComponent::import] No such directory:
>> "/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/gnulinux"
>> 22.375 [ Info ][Logger] Ignoring deployment shutdown function due to
>> missing peer.
>> ------
>>
>> Now I am back to the situation where the import() statement consistently
>> throws an error. I don't know why there was a short interval of time where
>> it did not do so.
>>
>>
>>> Normally, the import() statement only throws if a 'corrupt' package
>>> structure was found (for example, a bad .so file, not correctly
>>> linked). Not finding a package should just return false. So do check
>>> if all libraries of this package could resolve their link dependencies
>>> correctly (it should since this is a dummy package).
>>
>>
>> ldd
>> /home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/libwireless-gnulinux.so
>>
>> shows no unresolved dependencies.
>>
>> /Sagar
>>
>>
>>> On Fri, Oct 12, 2012 at 11:17 AM, Sagar Behere<sagar [dot] behere [..] ...>
>>> wrote:
>>>>
>>>> On the master branch, after creating an empty component with
>>>>
>>>> orocreate-pkg wireless component
>>>>
>>>> and build+install'ing it, I tried to load the component in the deployer.
>>>> It throws an exception and claims operation wasn't completed, but the
>>>> component is imported anyway!?
>>>>
>>>>
>>>>
>>>> ------
>>>> Deployer [S]>
>>>> import("/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/")
>>>> The command
>>>> 'import("/home/sagar/excludes/tmp/lib/orocos/gnulinux/wireless/")'
>>>> caused a std::exception: 'Unable to complete the operation call. The
>>>> called operation has thrown an exception' and could not be completed.
>>>> Deployer [X]> displayComponentTypes ()
>>>> I can create the following component types:
>>>> OCL::ConsoleReporting
>>>> OCL::FileReporting
>>>> OCL::HMIConsoleOutput
>>>> OCL::HelloWorld
>>>> OCL::LuaComponent
>>>> OCL::LuaTLSFComponent
>>>> OCL::TcpReporting
>>>> OCL::TimerComponent
>>>> OCL::logging::Appender
>>>> OCL::logging::FileAppender
>>>> OCL::logging::LoggingService
>>>> OCL::logging::OstreamAppender
>>>> TaskContext
>>>> Wireless
>>>> = =
>>>>
>>>> Deployer [X]> loadComponent("Wireless", "Wireless")
>>>> Wireless constructed !
>>>> = true
>>>>
>>>> Deployer [X]>
>>>> ------
>>>>
>>>> How to check why the exception is throw, and if it is indeed a problem?
>>>>
>>>> Regards,
>>>> Sagar
>>>> --
>>>> Orocos-Users mailing list
>>>> Orocos-Users [..] ...
>>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>