Oh, probably standard locale is not available on that machine, so the
conditional compilation prevents the leak from showing up.
Looks like I'll need access to a machine on which the leak occurs (and
which has valgrind) in order to fix that one.
Bill.
2009/1/10 Bill Hart <goodwillh...@googlemail.com>:
> Hmm, when I valgrind t-locale on sage.math, no leaks show up. What am
> I doing wrong?
>
> Bill.
>
> 2009/1/10 Bill Hart <goodwillh...@googlemail.com>:
>> Oh wait, C++ doesn't clean up automatically. The new needs to have a
>> corresponding delete!!
>>
>> Bill.
>>
>> 2009/1/10 Bill Hart <goodwillh...@googlemail.com>:
>>> Sorry, that should say:
>>>
>>> "whose constructor is:
>>>
>>> explicit numpunct(
>>> size_t _Refs = 0
>>> );"
>>>
>>> Bill.
>>>
>>> 2009/1/10 Bill Hart <goodwillh...@googlemail.com>:
>>>>
>>>> I've been taking a look at the memory leak in t-locale. According to
>>>> the valgrind log there is a leak due to operator new(unsigned long) in
>>>> set_point when called from check_output().
>>>>
>>>> Here is the relevant code:
>>>>
>>>> char point_string[2];
>>>>
>>>> #if HAVE_STD__LOCALE
>>>> // Like std::numpunct, but with decimal_point coming from point_string
>>>> [].
>>>> class my_numpunct : public numpunct<char> {
>>>> public:
>>>> explicit my_numpunct (size_t r = 0) : numpunct<char>(r) { }
>>>> protected:
>>>> char do_decimal_point() const { return point_string[0]; }
>>>> };
>>>> #endif
>>>>
>>>> void
>>>> set_point (char c)
>>>> {
>>>> point_string[0] = c;
>>>>
>>>> #if HAVE_STD__LOCALE
>>>> locale loc (locale::classic(), new my_numpunct ());
>>>> locale::global (loc);
>>>> #endif
>>>> }
>>>>
>>>> void
>>>> check_output (void)
>>>> {
>>>> static char point[] = {
>>>> '.', ',', 'x', '\xFF'
>>>> };
>>>>
>>>> for (size_t i = 0; i < numberof (point); i++)
>>>> {
>>>> set_point (point[i]);
>>>> ostringstream got;
>>>>
>>>> // <snip>
>>>> }
>>>> }
>>>>
>>>> It seems to me that the "new my_numpunct ()" is the culprit. The
>>>> constructor just calls the constructor for the standard numpunct
>>>> class, whose destructor is:
>>>>
>>>> explicit numpunct(
>>>> size_t _Refs = 0
>>>> );
>>>>
>>>> As size_t is probably an int of 4 bytes, it looks like that never gets
>>>> cleaned up. Apparently the destructor for that class is protected.
>>>>
>>>> My knowledge of C++ doesn't enable me to see a solution to this. Does
>>>> anyone else know how to force cleanup of excrement like this?
>>>>
>>>> Bill.
>>>>
>>>>
>>>> >>>>
>>>>
>>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
