Memory leak in boost::filesystems::parent_path()?
Hi, The following minimal program (only 7 lines) causes valgrind to report 2 errors, in line6: Some somebody point me to why it is wrong? a.cpp: 1 #include <boost/filesystem.hpp> 2 3 int main( int, char** ) 4 { 5 boost::filesystem::path path0( "/a/b/c" ); 6 boost::filesystem::path path1 = path0.parent_path(); 7 } Compiling and running with valgrind: g++ -g -lboost_system -lboost_filesystem a.cpp -o a.exe valgrind ./a.exe This gives the following output. Note the errors. ==13303== Memcheck, a memory error detector ==13303== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13303== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13303== Command: ./a.exe ==13303== ==13303== Invalid read of size 8 ==13303== at 0x5B0A5C8: wcscmp (in /lib64/libc-2.18.so) ==13303== by 0x52CA5C4: std::moneypunct<wchar_t, false>::~moneypunct() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52CA638: std::moneypunct<wchar_t, false>::~moneypunct() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52C1304: std::locale::_Impl::~_Impl() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52C143C: std::locale::~locale() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x5AA775E: __cxa_finalize (in /lib64/libc-2.18.so) ==13303== by 0x503DD72: ??? (in /usr/lib64/libboost_filesystem.so.1.53.0) ==13303== by 0x400EE69: _dl_fini (in /lib64/ld-2.18.so) ==13303== by 0x5AA73D8: __run_exit_handlers (in /lib64/libc-2.18.so) ==13303== by 0x5AA7424: exit (in /lib64/libc-2.18.so) ==13303== by 0x5A90BEB: (below main) (in /lib64/libc-2.18.so) ==13303== Address 0x604c038 is 0 bytes after a block of size 8 alloc'd ==13303== at 0x4C284B7: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13303== by 0x52CBC81: std::moneypunct<wchar_t, false>::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib64/libstdc++.so.6 .0.18) ==13303== by 0x52C3807: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52C42D1: std::locale::locale(char const*) (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x50451B1: boost::filesystem::path::codecvt() (in /usr/lib64/libboost_filesystem.so.1.53.0) ==13303== by 0x5046C7E: boost::filesystem::path::parent_path() const (in /usr/lib64/libboost_filesystem.so.1.53.0) ==13303== by 0x401843: main (a.cpp:6) ==13303== ==13303== Invalid read of size 8 ==13303== at 0x5B0A5C8: wcscmp (in /lib64/libc-2.18.so) ==13303== by 0x52CA4D4: std::moneypunct<wchar_t, true>::~moneypunct() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52CA548: std::moneypunct<wchar_t, true>::~moneypunct() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52C1304: std::locale::_Impl::~_Impl() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52C143C: std::locale::~locale() (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x5AA775E: __cxa_finalize (in /lib64/libc-2.18.so) ==13303== by 0x503DD72: ??? (in /usr/lib64/libboost_filesystem.so.1.53.0) ==13303== by 0x400EE69: _dl_fini (in /lib64/ld-2.18.so) ==13303== by 0x5AA73D8: __run_exit_handlers (in /lib64/libc-2.18.so) ==13303== by 0x5AA7424: exit (in /lib64/libc-2.18.so) ==13303== by 0x5A90BEB: (below main) (in /lib64/libc-2.18.so) ==13303== Address 0x604c268 is 0 bytes after a block of size 8 alloc'd ==13303== at 0x4C284B7: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13303== by 0x52CB6B1: std::moneypunct<wchar_t, true>::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib64/libstdc++.so.6. 0.18) ==13303== by 0x52C3854: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x52C42D1: std::locale::locale(char const*) (in /usr/lib64/libstdc++.so.6.0.18) ==13303== by 0x50451B1: boost::filesystem::path::codecvt() (in /usr/lib64/libboost_filesystem.so.1.53.0) ==13303== by 0x5046C7E: boost::filesystem::path::parent_path() const (in /usr/lib64/libboost_filesystem.so.1.53.0) ==13303== by 0x401843: main (a.cpp:6) ==13303== ==13303== ==13303== HEAP SUMMARY: ==13303== in use at exit: 0 bytes in 0 blocks ==13303== total heap usage: 483 allocs, 483 frees, 34,115 bytes allocated ==13303== ==13303== All heap blocks were freed -- no leaks are possible ==13303== ==13303== For counts of detected and suppressed errors, rerun with: -v ==13303== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
On 23 Apr 2014 at 4:15, B.W.H. van Beest wrote:
The following minimal program (only 7 lines) causes valgrind to report 2 errors, in line6:
Some somebody point me to why it is wrong?
Both are bugs in libstdc++. They've been there for years. Should be fixed now in upstream, so upgrade your OS. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Thanks for the answer. You say 'should be fixed by now'. But I have a recent OS, openSuSe 13.1, regularly updated. version of libstdc== is: 4.8.1. (from: ) chopin:~ # rpm -q -a | grep libstdc++ libstdc++6-32bit-4.8.1_20130909-3.2.1.x86_64 libstdc++6-4.8.1_20130909-3.2.1.x86_64 libstdc++-devel-4.8-2.1.2.x86_64 libstdc++48-devel-4.8.1_20130909-3.2.1.x86_64 Do you know if the bug actually has been fixed? Kind Regards, Bertwim On 04/23/2014 11:52 AM, Niall Douglas [via Boost] wrote:
On 23 Apr 2014 at 4:15, B.W.H. van Beest wrote:
The following minimal program (only 7 lines) causes valgrind to report 2 errors, in line6:
Some somebody point me to why it is wrong?
Both are bugs in libstdc++. They've been there for years. Should be fixed now in upstream, so upgrade your OS.
Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
_______________________________________________ Boost-users mailing list [hidden email] </user/SendEmail.jtp?type=node&node=4661604&i=0> http://lists.boost.org/mailman/listinfo.cgi/boost-users
*SMime.p7s* (8K) Download Attachment <http://boost.2283326.n4.nabble.com/attachment/4661604/0/SMime.p7s>
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://boost.2283326.n4.nabble.com/Memory-leak-in-boost-filesystems-parent-p...
To start a new topic under Boost - Users, email ml-node+s2283326n2553780h57@n4.nabble.com To unsubscribe from Boost, click here <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2553779&code=Ynd2YkB4czRhbGwubmx8MjU1Mzc3OXwtNjM4MDQ0NjQ5>. NAML <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://boost.2283326.n4.nabble.com/Memory-leak-in-boost-filesystems-parent-p... Sent from the Boost - Users mailing list archive at Nabble.com.
On 23 Apr 2014 at 9:24, Bertwim van Beest wrote:
You say 'should be fixed by now'. But I have a recent OS, openSuSe 13.1, regularly updated. version of libstdc== is: 4.8.1.
Do you know if the bug actually has been fixed?
I had understood it's fixed in trunk. Might have been backported to 4.9. I'd just add the relevant reports to a default suppressions file for the system and never worry about them again. Unfortunately, there is also undefined behaviour in libstdc++ which triggers a clang undefined behaviour sanitiser report every program run which cannot be easily suppressed, but is also apparently fixed in 4.9 - until then you have to use sed to filter the reports so the CI reports green :( Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Ok. Thanks for explaining the situation. Kind Regards, Bertwim On 04/24/2014 01:06 PM, Niall Douglas wrote:
On 23 Apr 2014 at 9:24, Bertwim van Beest wrote:
You say 'should be fixed by now'. But I have a recent OS, openSuSe 13.1, regularly updated. version of libstdc== is: 4.8.1.
Do you know if the bug actually has been fixed? I had understood it's fixed in trunk. Might have been backported to 4.9.
I'd just add the relevant reports to a default suppressions file for the system and never worry about them again. Unfortunately, there is also undefined behaviour in libstdc++ which triggers a clang undefined behaviour sanitiser report every program run which cannot be easily suppressed, but is also apparently fixed in 4.9 - until then you have to use sed to filter the reports so the CI reports green :(
Niall
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
B.W.H. van Beest -
Bertwim van Beest
-
Niall Douglas