Opened 9 years ago
Closed 9 years ago
#9181 closed Bugs (invalid)
memory leak in Date_Time
Reported by: | Owned by: | az_sw_dude | |
---|---|---|---|
Milestone: | To Be Determined | Component: | date_time |
Version: | Boost 1.48.0 | Severity: | Problem |
Keywords: | Date_Time memory leak | Cc: | mail@… |
Description
It looks like there is a memory leak when streaming Date_Time objects to standard output. Consider the following simple code:
#include <boost/date_time/posix_time/posix_time.hpp> #include <iostream>
using namespace boost::posix_time;
int main() {
ptime time(boost::gregorian::date(2013, 9, 30), hours(14) + minutes(42)); std::cout << time << '\n'; std::cout << time.date() << '\n'; std::cout << time.date().month() << '\n'; std::cout << time.time_of_day() << '\n';
}
Compiling: g++ -lboost_date_time bug.cpp Testing: valgrind ./a.out
==8994== Memcheck, a memory error detector ==8994== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==8994== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==8994== Command: ./a.out ==8994== 2013-Sep-30 14:42:00 2013-Sep-30 Sep 14:42:00 ==8994== ==8994== HEAP SUMMARY: ==8994== in use at exit: 2,491 bytes in 49 blocks ==8994== total heap usage: 82 allocs, 33 frees, 8,448 bytes allocated ==8994== ==8994== LEAK SUMMARY: ==8994== definitely lost: 0 bytes in 0 blocks ==8994== indirectly lost: 0 bytes in 0 blocks ==8994== possibly lost: 1,187 bytes in 39 blocks ==8994== still reachable: 1,304 bytes in 10 blocks ==8994== suppressed: 0 bytes in 0 blocks ==8994== Rerun with --leak-check=full to see details of leaked memory ==8994== ==8994== For counts of detected and suppressed errors, rerun with: -v ==8994== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
(please find the --leak-check=full output attached). I'm using Ubuntu 12.04 LTS, Boost 1.48.0-3, and gcc 4.6.3.
Attachments (1)
Change History (4)
by , 9 years ago
follow-up: 2 comment:1 by , 9 years ago
Cc: | added |
---|
I've reproduced your valgrind output on Fedora 19 (boost 1.53, gcc 4.8.2).
The source seems to be
/usr/include/boost/date_time/gregorian/gregorian_io.hpp:62
custom_date_facet* f = new custom_date_facet();
and
/usr/include/boost/date_time/posix_time/posix_time_io.hpp:59
custom_ptime_facet* f = new custom_ptime_facet();
inside a operator<<()
definition.
But this memory leak is constant, i.e. it does not grow with the number of output operator calls - because it is guarded by:
if (std::has_facet<custom_ptime_facet>(os.getloc())) { // use allocated facet } else { // allocate facet }
The else branch has a comment that reads:
//instantiate a custom facet for dealing with times since the user //has not put one in the stream so far. This is for efficiency //since we would always need to reconstruct for every time period //if the locale did not already exist. Of course this will be overridden //if the user imbues as some later point.
comment:2 by , 9 years ago
Replying to Georg Sauthoff <mail@…>:
I've reproduced your valgrind output on Fedora 19 (boost 1.53, gcc 4.8.2).
The source seems to be
/usr/include/boost/date_time/gregorian/gregorian_io.hpp:62
custom_date_facet* f = new custom_date_facet();and
/usr/include/boost/date_time/posix_time/posix_time_io.hpp:59
custom_ptime_facet* f = new custom_ptime_facet();inside a
operator<<()
definition.
This is not a leak. The ownership of the facet is transferred to the locale object. The facet will be deleted when the locale is.
Regarding the valgrind report, I think this is due to the fact that the locale does not get deleted when valgrind makes its report. This is because standard streams are not destroyed at this point.
You can try adding "std::cout.imbue(std::locale())" at the end of your main() and see if the facet is deleted then.
comment:3 by , 9 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
valgrind output