Re: [Flightgear-devel] Valgrind logs
Am 14.04.2011 21:39, schrieb Torsten Dreyer: Isn't that what SGReferenced objects were made for? Automatic deletion? Minimal but slight more complex example [...] yes, this works as expected -- as long as one uses SGSharedPtr. The componentForge map uses standard pointers at the moment, so it doesn't work here. However, I have no idea how SGSharedPtr can be used in combination with functor, static mapstring,SGSharedPtrFunctorBaseDigitalFilterImplementation componentForge; doesn't even compile. The input value lists seems to fulfil both conditions (SGSharedPtr pointing to SGReferenced), so in theory, automatic deletion should work here. Still, valgrind complains. Could the problem here be related to calling the componentForge functor? Best regards, Andreas -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Valgrind logs
On 15.04.2011 11:11, Andreas Gaeb wrote: The input value lists seems to fulfil both conditions (SGSharedPtr pointing to SGReferenced), so in theory, automatic deletion should work here. Still, valgrind complains. Could the problem here be related to calling the componentForge functor? Remember that SGReferenced does reference counting. In theory, the root cause could be completely elsewhere in the code, if there were other references to the same InputValue. If only a single of these references wasn't removed, then the actual InputValue object is never deleted (and let's hope there are no cyclic references anywhere...). cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Valgrind logs
Hello everybody, a valgrind log of recent FlightGear is available from http://dl.dropbox.com/u/15761796/valgrind.log (13 MB). A short version containing only the definitely lost backtraces is at http://dl.dropbox.com/u/15761796/definitely_lost.log (59 kB). The largest single entry stems from the TrafficMgr code. It is fixed by the attached patch, which deletes all scheduled flights. However, as I quit the program as soon as the 3D clouds showed up, I suspect that with increased run time other leaks might become more important, possibly the ones regarding simgear/scene/model/SGReaderWriterXML.cxx:289. Some things that might be fixed relatively easy: FG/src/Autopilot/digitalfilter.cxx: all InputValues pushed_back to one of the InputValueLists need to be deleted FG/src/Autopilot/digitalfilter.cxx:316: members of componentForge need to be deleted FG/src/Autopilot/autopilot.cxx:46: the same FG/src/Instrumentation/gps.cxx:1575: _currentWaypt needs to be deleted FG/src/AIModel/performancedb.cxx:88 members of _db need to be deleted Hope this helps a little in stuffing the sieve, best regards, Andreas Thanks for looking into this. A few comments on the autopilot objects: InputValueLists are vectors of InputValue, a subclass of SGReferenced, so they should be automatically deleted, once the last reference is gone? The componentForge is a static vector, initialized only once at startup. It's intention is to live during the entire session. It's never dropped, never recreated and never cleared. Torsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Valgrind logs
Am 14.04.2011 16:58, schrieb Torsten Dreyer:
Thanks for looking into this.
A few comments on the autopilot objects:
InputValueLists are vectors of InputValue, a subclass of SGReferenced, so
they
should be automatically deleted, once the last reference is gone?
The componentForge is a static vector, initialized only once at startup. It's
intention is to live during the entire session. It's never dropped, never
recreated and never cleared.
The thing with maps and vectors of pointers to heap objects is that --
according to valgrind -- the heap objects are not deleted when the
parent vector is. Minimal example:
#include vector
int main() {
std::vectorint* v;
v.push_back(new int(1));
v.clear();
return 0;
}
leaks 4 bytes in spite of the clear() call. It is necessary to delete
the heap objects explicitly, e.g.
std::vectorint*::iterator i;
for (i=v.begin(); i != v.end(); ++i)
delete (*i);
This doesn't happen for static variables nor for data members. I'd
assume that in case of SGReferenced objects, the same explicit delete is
necessary to decrement the reference counter.
In any case, the static variables and probably the complete autopilot
are only destroyed at program end, so fixing these leaks won't have an
influence on the growing memory footprint at runtime. I just mentioned
them because they were the only ones where I thought an easy fix to be
possible.
Best regards,
Andreas
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Valgrind logs
This doesn't happen for static variables nor for data members. I'd
assume that in case of SGReferenced objects, the same explicit delete is
necessary to decrement the reference counter.
Isn't that what SGReferenced objects were made for? Automatic deletion?
Minimal but slight more complex example
class MyReferenced : public SGReferenced {
public:
MyReferenced( int id );
virtual ~ MyReferenced();
private:
int _id;
};
MyReferenced::MyReferenced( int id ) :
_id(id)
{
std::cerr MyReferenced( _id ) constructed std::endl;
}
MyReferenced::~MyReferenced()
{
std::cerr MyReferenced( _id ) destructed std::endl;
}
int main(int argc, char **argv )
{
std::vectorSGSharedPtrMyReferenced v;
std::cerr Adding first std::endl;
v.push_back(new MyReferenced(1));
std::cerr Adding second std::endl;
v.push_back(new MyReferenced(2));
std::cerr Clearing Vector std::endl;
v.clear();
std::cerr Exiting std::endl;
return 0;
}
Creates output as expected:
Adding first
MyReferenced(1) constructed
Adding second
MyReferenced(2) constructed
Clearing Vector
MyReferenced(1) destructed
MyReferenced(2) destructed
Exiting
And without the explicit clear(), it looks right, too:
Adding first
MyReferenced(1) constructed
Adding second
MyReferenced(2) constructed
Exiting
MyReferenced(1) destructed
MyReferenced(2) destructed
In any case, the static variables and probably the complete autopilot
are only destroyed at program end, so fixing these leaks won't have an
influence on the growing memory footprint at runtime. I just mentioned
them because they were the only ones where I thought an easy fix to be
possible.
Which is very much appreciated. It's just to easy to overlook something.
Torsten
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
