|
From: Freedrive101 <fre...@gm...> - 2007-08-06 21:32:24
|
Hi, today i used valgrind for the first time... valgrind says it found 2 leaks... but iam not sure if those really are leaks or if it is just false alarm. maybe it´s a leak and if so i don´t know how to fix it. i hope i include all the files needed to spot this leak: first the valgrind output (valgrind.txt) then the cVector class that seems to leak (vector.h) and the iObject class that uses cVector (only the lines needed object.cpp) i appreciate every help and information i get Regards john |
|
From: Jason C. <co...@cc...> - 2007-08-06 22:09:16
|
Freedrive101 wrote: > Hi, > > today i used valgrind for the first time... > > valgrind says it found 2 leaks... but iam not sure if those really are > leaks > or if it is just false alarm. maybe it´s a leak and if so i don´t > know how to fix it. > > i hope i include all the files needed to spot this leak: > first the valgrind output (valgrind.txt) > then the cVector class that seems to leak (vector.h) > and the iObject class that uses cVector (only the lines needed > object.cpp) > > i appreciate every help and information i get > I advise you ignore the memory leaks until you've fixed the more severe errors - namely ==9130== Invalid free() / delete / delete[] ==9130== at 0x40049B3: operator delete[](void*) (vg_replace_malloc.c:256) ==9130== by 0x80498A7: physic::cVector<double>::~cVector() (vector.h:158) ==9130== by 0x804B1A1: physic::iObject::~iObject() (object.cpp:151) ==9130== by 0x804A12F: physic::cMenu::addObjects() (menu.cpp:109) ==9130== by 0x804A260: physic::cMenu::runMenu() (menu.cpp:30) ==9130== by 0x8049965: main (main.cpp:22) Off-topic C++ advise: I suggest you avoid raw pointers;you could use a boost shared array to hold the pointer to your raw arrays which would mean you would not need to explicitly free your data (see http://www.boost.org/libs/smart_ptr/smart_ptr.htm for more info). Alternatively - unless you really really think you can write a vector better than C++ compiler implementors - consider using an STL vector to contain your data; J. > Regards > john > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users LEGAL NOTICE Unless expressly stated otherwise, information contained in this message is confidential. If this message is not intended for you, please inform pos...@cc... and delete the message. The Cambridge Crystallographic Data Centre is a company Limited by Guarantee and a Registered Charity. Registered in England No. 2155347 Registered Charity No. 800579 Registered office 12 Union Road, Cambridge CB2 1EZ. |
|
From: Freedrive101 <fre...@gm...> - 2007-08-07 22:19:43
|
> Off-topic C++ advise: I suggest you avoid raw pointers;you could use a > boost shared array to hold the pointer to your raw arrays which would > mean you would not need to explicitly free your data (see > http://www.boost.org/libs/smart_ptr/smart_ptr.htm for more info). thx for this suggestion i agree that smart pointers make life a lot easier but if i encapsulate the pointer in a class iam not sure if the overhead is necessary... maybe i will change the raw pointer to a shared one > Alternatively - unless you really really think you can write a vector > better than C++ compiler implementors - consider using an STL vector to > contain your data; i think i like to reinvent the wheel.. i know that might be a weakness but i learn a lot about data structures that way (i hope) i finally found the source of my problem: i did not overload the assignment operator (a problem that could have been avoided with shared pointers) |
|
From: Christoph B. <bar...@or...> - 2007-08-08 07:42:50
|
> > Alternatively - unless you really really think you can write a vector > > better than C++ compiler implementors - consider using an STL vector to > > contain your data; > > i think i like to reinvent the wheel.. i know that might be a weakness but > i learn a lot about data structures that way (i hope) > > i finally found the source of my problem: > i did not overload the assignment operator (a problem that could have been > avoided with shared > pointers) You should also read appendix E of the C++ Programming book by Bjarne Stroustrup. It talks about implementing vector and exception safety. Christoph |