For more infomation about this bug, visit
--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2008-05-11 19:41:19 ---
Created an attachment (id=283)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=283)
v1.4 log
[Bug 547] Trunk's Reporting component fails to report
| Submitted by snrkiwi on Sun, 2008-05-11 17:41 |
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
--- Comment #2 from S Roderick <kiwi [dot] net [..] ...> 2008-05-11 19:42:18 ---
Created an attachment (id=284)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=284)
Diff for logging additions in deployment component
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2008-05-11 19:42:57 ---
Created an attachment (id=285)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=285)
Deployment file
[Bug 547] New: Trunk's Reporting component fails to report
For more infomation about this bug, visit
Summary: Trunk's Reporting component fails to report
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Reporting
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
Created an attachment (id=282)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=282)
Output from trunk's deployer-gnulinux
The attached deployment file runs and creates a report with v1.4.0, but does
not with trunk. The AutoStart and AutoConf values in the reporting component
appear to get reset at some point, but I can not figure out where. Note that
the attached deployment file has no peers for the Reporting component to
actually report, but I first noticed the behaviour with several peers to
report.
The deployment component shows that it is valid. The reporting component is
definitely configuring itself, it just appears that the deployment component
chooses to not start the reporter. I've looked at this for a few hours now, and
can't figure out either a) what's wrong, or b) what I'm not understanding.
In log-trunk you can see the AutoStart and AutoConf being set at lines 35 and
36, but then at lines 57 and 61 you can see their values are not different
(these output lines are additions I made to DeploymentComponent.cpp)
In log-v1.4 you can see the report configure itself from file at line 202. This
never occurs with trunk.
I've also attached my mod's to DeploymentComponent.cpp, to verify that I only
added logging lines (and there _should_ have affected nothing!).
_We_ must be doing something wrong at our end, as this worked a couple of weeks
ago and I see nothing in the SVN log's to account for any change in behaviour
of the Deployment component.
TIA
S
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
Peter Soetens
<peter [dot] soetens [..] ...> changed:
What |Removed |Added
--------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #8 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-30 09:12:52 ---
Reporter confirmed fix. patch applied on trunk/ocl.
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
--- Comment #7 from S Roderick <kiwi [dot] net [..] ...> 2008-05-12 14:54:40 ---
(In reply to comment #6)
> Since I'm in the process of upgrading my Ubuntu laptop (and I remove compilers
> before upgrading...), I couldn't compile this patch.
Confirm that this fixes the bug.
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
--- Comment #6 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-11 22:38:32 ---
Created an attachment (id=286)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=286)
Fixes autoconf and autostart being overwritten in loadComponent()
Because of a previous commit, the options are read before the component is
created (instead of after), the loadComponent() function assumed the options
were not set and overwrote them with the default.
Since I'm in the process of upgrading my Ubuntu laptop (and I remove compilers
before upgrading...), I couldn't compile this patch.
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
--- Comment #5 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-11 22:28:43 ---
Got it.. fixing it. My bug.
[Bug 547] Trunk's Reporting component fails to report
> --- Comment #5 from Peter Soetens
<peter [dot] soetens [..] ...> > 2008-05-11 22:28:43 ---
> Got it.. fixing it. My bug.
Ok, that was _incredibly_ quick! I barely had a chance to digest your
last email .... :-)
[Bug 547] Trunk's Reporting component fails to report
For more infomation about this bug, visit
Peter Soetens
<peter [dot] soetens [..] ...> changed:
What |Removed |Added
--------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |peter [dot] soetens [..] ...
Target Milestone|--- |1.6.0
--- Comment #4 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-11 22:23:46 ---
Could you also run your deployer-gnulinux through valgrind in order to be sure
that we are not chasing a pointer/memory error ?
Thanks,
Peter
[Bug 547] Trunk's Reporting component fails to report
> --- Comment #4 from Peter Soetens
<peter [dot] soetens [..] ...> > 2008-05-11 22:23:46 ---
> Could you also run your deployer-gnulinux through valgrind in order
> to be sure
> that we are not chasing a pointer/memory error ?
Wilco. Same thought re pointer/memory error crossed my mind. The error
behaviour is just too odd ...
Personally, I'll place money on the fact that I'm doing something
dumb .... wouldn't be the first time ... ;-)