[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:21:54 ---
Created an attachment (id=296)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=296)
deployer-corba log

[Bug 554] New: ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit
Summary: ctaskbrowser seg faults on port of KDL data type
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Deployment
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Created an attachment (id=295)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=295)
ctaskbrowser log file

Believe related to http://www.orocos.org/node/683

We are running a naming service and using deployer-corba and ctaskbrowser both
on the same machine. The latest patches to RTT for this problem allow us to see
connected ports at ctaskbrowser, however, when ctaskbrowser encounters a KDL
type (a frame in this case) it seg-faults after emitting "Can not create a
proxy for data connection".

How do we get ctaskbrowser to load the KDL plugin library? (which we presume
will fix this particular problem).

Attached are the logs from the ctaskbrowser and deployer-corba.

Cheers
S

[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

--- Comment #7 from S Roderick <kiwi [dot] net [..] ...> 2008-05-22 22:42:07 ---
(In reply to comment #6)
> We certainly need to get rid of the segfault 'behavior' asap. I've done the
> necessary changes in RTT to avoid null pointer returns when a type is unknown.

Is this checked into trunk then?

> Next a simple 'import("/path/to/kdl-plugin")' should make KDL types available.

The Toolkit::Import() with the KDL plugin works fine, but it won't work with
the Corba plugin. That plugin appears to only support dynamic loading - the
Corba loadRttPlugin() just registers transport with Corba, it doesn't actually
"import" the toolkit. I had to import KDL and use dynamic plugin loading to get
KDL Corba. This looks like it might be an easy fix by just adding the
Toolkit::Import() line into the corba logRttPlugig() function, but does this
have any side effects?

> Note that we have two libraries: one which is the KDL type plugin and one which
> is the KDL corba plugin... Both are required in your case. I'm still not
> completely satisfied with the current way of loading plugins. Any ideas are
> still welcome.

Re loading plugins, a couple of ideas for just the taskbrowser case 1) have
command line arg's specify plugins to load (eg ctaskbrowser --load
/path/to/kdlplugin ...) and/or 2) take some of the deployment functionality and
drop it into the taskbrowser so that it can use a (simplified) XML file to
"import" libraries/plugins.

[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

Peter Soetens

<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...

--- Comment #6 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-22 22:14:55 ---
We certainly need to get rid of the segfault 'behavior' asap. I've done the
necessary changes in RTT to avoid null pointer returns when a type is unknown.
Next a simple 'import("/path/to/kdl-plugin")' should make KDL types available.
Note that we have two libraries: one which is the KDL type plugin and one which
is the KDL corba plugin... Both are required in your case. I'm still not
completely satisfied with the current way of loading plugins. Any ideas are
still welcome.

[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

--- Comment #5 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 16:33:58 ---
Adding run-time dynamic load of the KDL Corba plugin (lifted code from
DeploymentComponent.cpp) as well as the compile-time import of KDL fixes this
problem.

So the question is am I doing this completely wrong, or if not, how do we
structure proper modifications to ctaskbrowser to allow the user to load
plugins, etc, at runtime??

Cheers
S

[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

--- Comment #4 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:50:22 ---
Created an attachment (id=298)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=298)
deployer-corba log from ctaskbrowser with explicit KDL toolkit import

[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:49:58 ---
Created an attachment (id=297)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=297)
Log from ctaskbrowser with explicit KDL toolkit import

[Bug 554] ctaskbrowser seg faults on port of KDL data type

For more infomation about this bug, visit

--- Comment #2 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:49:26 ---
Explicitly added import of KDL toolkit into ctaskbrowser.cpp, and now we get a
different seg fault. :-(

"Corba: Do not know how to narrow to frame"

Logs attached.
S