For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637>
Summary: Deployer locks computer under Xenomai, if fails to
cleanly configure/start components
Product: OCL
Version: unspecified
Platform: All
OS/Version: Xenomai 2.x
Status: NEW
Severity: critical
Priority: P3
Component: Deployment
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
Under Xenomai (2.4.4 patched against a 2.6.25.20 kernel, running under Debian
Lenny distro), if the deployer fails to cleanly start up (ie can't find a
library, or can't find a remote corba component, etc) then upon exiting the
deployer the entire machine locks up and a hard reboot is required.
I've noticed a similar nasty exit from the deployer under non-Xenomai Linux -
sometimes you have to Ctrl-C the deployer after it locked up while exiting. It
does not, however, lock the machine up.
I presume the two issues are related.
Could this behaviour be application specific and related to partially connected
components?
[Bug 637] Deployer locks computer under Xenomai, if fails to cle
For more infomation about this bug, visit https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637
Peter Soetens <peter [dot] soetens [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution| |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #4 from Peter Soetens <peter [dot] soetens [..] ...> 2009-03-23 09:41:09 ---
Reporter confirmed fix on orocos-dev ML.
[Bug 637] Deployer locks computer under Xenomai, if fails to cle
For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637>
--- Comment #3 from Peter Soetens <peter [dot] soetens [..] ...> 2009-03-20 17:20:50 ---
Created an attachment (id=406)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=406)
mylyn/context/zip
[Bug 637] Deployer locks computer under Xenomai, if fails to cle
For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637>
--- Comment #2 from Peter Soetens <peter [dot] soetens [..] ...> 2009-03-20 17:20:49 ---
Created an attachment (id=405)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=405)
Fix infinite loop in component unload implementation.
The loop didn't erase the component structure when loading had only partially
succeeded.
[Bug 637] Deployer locks computer under Xenomai, if fails to cle
On Mar 20, 2009, at 12:20 , Peter Soetens wrote:
> For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637
> >
>
>
>
>
> --- Comment #2 from Peter Soetens <peter [dot] soetens [..] ...>
> 2009-03-20 17:20:49 ---
> Created an attachment (id=405)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=405)
> Fix infinite loop in component unload implementation.
>
> The loop didn't erase the component structure when loading had only
> partially
> succeeded.
Fixes behaviour under gnulinux, and also stops xenomai hard lockup.
Cheers :-)
S
[Bug 637] Deployer locks computer under Xenomai, if fails to cle
For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637>
Peter Soetens <peter [dot] soetens [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.8.0
CC| |peter [dot] soetens [..] ...
Status|NEW |ASSIGNED
--- Comment #1 from Peter Soetens <peter [dot] soetens [..] ...> 2009-03-19 15:04:14 ---
(In reply to comment #0)
> Under Xenomai (2.4.4 patched against a 2.6.25.20 kernel, running under Debian
> Lenny distro), if the deployer fails to cleanly start up (ie can't find a
> library, or can't find a remote corba component, etc) then upon exiting the
> deployer the entire machine locks up and a hard reboot is required.
Which means a hard-realtime (or Linux FIFO) thread goes into infinite loop.
>
> I've noticed a similar nasty exit from the deployer under non-Xenomai Linux -
> sometimes you have to Ctrl-C the deployer after it locked up while exiting. It
> does not, however, lock the machine up.
When it happens again (in gnulinux), could you attach gdb to the process and
save the backtrace ?
/path/to/deployer-gnulinux
hang!
gdb /path/to/deployer-gnulinux $(pidof deployer-gnulinux)
(gdb) bt
That should locate it quickly. I'll see if I can reproduce this with your
example scenario.
Peter
[Bug 637] Deployer locks computer under Xenomai, if fails to cle
On Mar 19, 2009, at 10:04 , Peter Soetens wrote:
> For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=637
> >
>
> Peter Soetens <peter [dot] soetens [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Target Milestone|--- |1.8.0
> CC| |peter [dot] soetens [..] ...
> Status|NEW |ASSIGNED
>
>
>
>
> --- Comment #1 from Peter Soetens <peter [dot] soetens [..] ...>
> 2009-03-19 15:04:14 ---
> (In reply to comment #0)
>> Under Xenomai (2.4.4 patched against a 2.6.25.20 kernel, running
>> under Debian
>> Lenny distro), if the deployer fails to cleanly start up (ie can't
>> find a
>> library, or can't find a remote corba component, etc) then upon
>> exiting the
>> deployer the entire machine locks up and a hard reboot is required.
>
> Which means a hard-realtime (or Linux FIFO) thread goes into
> infinite loop.
>
>>
>> I've noticed a similar nasty exit from the deployer under non-
>> Xenomai Linux -
>> sometimes you have to Ctrl-C the deployer after it locked up while
>> exiting. It
>> does not, however, lock the machine up.
>
> When it happens again (in gnulinux), could you attach gdb to the
> process and
> save the backtrace ?
>
> /path/to/deployer-gnulinux
> hang!
> gdb /path/to/deployer-gnulinux $(pidof deployer-gnulinux)
> (gdb) bt
>
> That should locate it quickly. I'll see if I can reproduce this with
> your
> example scenario.
Debian Lenny 2.6.26-1-686, ACE/TAO from Debian packages, Orocos r30002
Deployer failed to load any user application libraries (fresh install
of Lenny, forgot to run "ldconfig" prior).
HTH
S
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm