shared_ptr leaking memory and crashing / gcc 3.4.6
Hello, I figured that shared_ptr (boost 3.4, but I don't think this is really a boost problem) will lose memory in the following example #include <boost/shared_ptr.hpp> struct X { int y; }; typedef boost::shared_ptr<X> XRef; XRef getx() { throw 0; } int main(int argc, char** argv) { while (true) { XRef myX; try { myX = getx(); } catch(...) { } } } Compile: g++ -I/usr/local/include test.C -o test On every iteration of the while loop it loses memory and after approx. 1 million iterations it dies with signal 10 or 11. Changing that pattern to try { XRef y = getx(); myX = y; } catch(...) { } fixes the problem (I assume in that case it will call shared_ptrs copy constructor instead of its assignment operator). Platform is FreeBSD 6, gcc 3.4.6. It only happens when compiled like above (without optimization). On optimization levels 2 and above (-O2) it works ok. Maybe somebody using gcc 3.4 can check if this also happens on other platforms. gcc 4 works ok without any issues, so I assume this is a compiler problem. It might still be a good idea to put a warning in the documentation about this. cheers Michael
Anybody interested in this or could point me to a different boost list? Michael wrote:
Hello,
I figured that shared_ptr (boost 3.4, but I don't think this is really a boost problem) will lose memory in the following example
#include <boost/shared_ptr.hpp>
struct X { int y; }; typedef boost::shared_ptr<X> XRef;
XRef getx() { throw 0; }
int main(int argc, char** argv) { while (true) { XRef myX; try { myX = getx(); } catch(...) { } } }
Compile: g++ -I/usr/local/include test.C -o test
On every iteration of the while loop it loses memory and after approx. 1 million iterations it dies with signal 10 or 11.
Changing that pattern to try { XRef y = getx(); myX = y; } catch(...) { }
fixes the problem (I assume in that case it will call shared_ptrs copy constructor instead of its assignment operator).
Platform is FreeBSD 6, gcc 3.4.6. It only happens when compiled like above (without optimization). On optimization levels 2 and above (-O2) it works ok. Maybe somebody using gcc 3.4 can check if this also happens on other platforms. gcc 4 works ok without any issues, so I assume this is a compiler problem. It might still be a good idea to put a warning in the documentation about this.
cheers Michael
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Anybody interested in this or could point me to a different boost list?
Michael wrote:
Hello,
I figured that shared_ptr (boost 3.4, but I don't think this is really a boost problem) will lose memory in the following example ... int main(int argc, char** argv) { while (true) { XRef myX; try { myX = getx(); } catch(...) { } } } ... Platform is FreeBSD 6, gcc 3.4.6. It only happens when compiled like above (without optimization).
I'm interested in principle in everything concerning shared_ptr, but I'm not sure what we can do about this specific case. Maybe report it to the GCC Bugzilla? Is 3.4.6 even being maintained? -- Peter Dimov http://www.pdplayer.com
Peter Dimov wrote:
Anybody interested in this or could point me to a different boost list?
Michael wrote:
Hello,
I figured that shared_ptr (boost 3.4, but I don't think this is really a boost problem) will lose memory in the following example ... int main(int argc, char** argv) { while (true) { XRef myX; try { myX = getx(); } catch(...) { } } } ... Platform is FreeBSD 6, gcc 3.4.6. It only happens when compiled like above (without optimization).
I'm interested in principle in everything concerning shared_ptr, but I'm not sure what we can do about this specific case. Maybe report it to the GCC Bugzilla? Is 3.4.6 even being maintained? Thanks for your response.
I'm not certain if 3.4.6 is still maintained (the gcc site is not very specific about this), but since it is still shipped with some OSes as default I thought it might me worthwhile to put a warning somewhere in the boost documentation (sth like "known issues") to save somebody else from getting hit by this (in my case it was a server process crashing once a week for no apparent reason). Posting a bug at the gcc mailing list would only be an option if I can track this further down so I can report it without referring to boost (otherwise I'm pretty sure they will tell me to report this to the boost mailing list :). I don't know shared_ptr's internals (yet) and if this relates to something that is very specific to shared_ptr or a general issue that is easy to put in a small example case. So if you or anybody has a clue what might cause this I could try to get this to the gcc guys. If not, I would just suggest a warning in the documentation and hope that 3.4 won't be used by anybody in the near future. /michael
-- Peter Dimov http://www.pdplayer.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Michael: ...
int main(int argc, char** argv) { while (true) { XRef myX; try { myX = getx(); } catch(...) { } } }
...
Posting a bug at the gcc mailing list would only be an option if I can track this further down so I can report it without referring to boost (otherwise I'm pretty sure they will tell me to report this to the boost mailing list :).
FWIW, I have reported g++ bugs in the past that made boost::shared_ptr misbehave, and they did get acknowledged and fixed, so this might still be worth a try. I did not need to distill it down to an example that did not #include anything Boost, although I think I did follow http://gcc.gnu.org/bugs.html (that is, I did include self-contained preprocessed output.) -- Peter Dimov http://www.pdplayer.com
participants (4)
-
Michael -
Peter Dimov