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
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 map > > 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
> 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::vector > 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
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
int main() {
std::vector 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::vector::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
> 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
