memory leak in regex - 4.9.0

memory leak in regex - 4.9.0

[Lars Gullik Bjønnes]

Hi,

I have something that certainly looks like a memory leak.

-------------------
#include <regex>
#include <string>

int main()
{
        for (int i = 0; i < 10; ++i) {
                std::string s("leak");
                std::regex reg("ea");
                std::regex_match(s, reg);
        }
}
------------------

g++ --version
g++ (GCC) 4.9.0 20131014 (experimental)

g++ -std=gnu++11 -O2 leak.cpp

If I increase the amount of looping the leak reports
increases linearly.

All output from valgrind below. It might be regex or it might be some
allocator issue, I have seen something with std::deque as well outside
any regex context. Not been able to reproduce though.

Thanks.

valgrind --leak-check=full --gen-suppressions=all ./a.out 
==25728== Memcheck, a memory error detector
==25728== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==25728== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==25728== Command: ./a.out
==25728== 
==25728== 
==25728== HEAP SUMMARY:
==25728==     in use at exit: 32 bytes in 4 blocks
==25728==   total heap usage: 96 allocs, 92 frees, 5,075 bytes allocated
==25728== 
==25728== 8 bytes in 1 blocks are definitely lost in loss record 1 of 4
==25728==    at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25728==    by 0x405C06: std::unique_ptr<std::__detail::_Executor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> >, std::default_delete<std::__detail::_Executor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> > > > std::__detail::__get_executor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char>, (std::__detail::_RegexExecutorPolicy)0>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, std::vector<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, std::basic_regex<char, std::regex_traits<char> > const&, std::regex_constants::match_flag_type) (in /h/lgb/Development/test/a.out)
==25728==    by 0x405F05: bool std::__detail::__regex_algo_impl<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char>, (std::__detail::_RegexExecutorPolicy)0, true>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, std::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, std::basic_regex<char, std::regex_traits<char> > const&, std::regex_constants::match_flag_type) (in /h/lgb/Development/test/a.out)
==25728==    by 0x401FF5: main (in /h/lgb/Development/test/a.out)
==25728== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:_Znwm
   fun:_ZNSt8__detail14__get_executorIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcELNS_20_RegexExecutorPolicyE0EEESt10unique_ptrINS_9_ExecutorIT_T0_T1_T2_EESt14default_deleteISI_EESE_SE_RSt6vectorIS6_ISE_ESF_ERKSt11basic_regexISG_SH_ENSt15regex_constants15match_flag_typeE
   fun:_ZNSt8__detail17__regex_algo_implIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcELNS_20_RegexExecutorPolicyE0ELb1EEEbT_SC_RSt13match_resultsISC_T0_ERKSt11basic_regexIT1_T2_ENSt15regex_constants15match_flag_typeE
   fun:main
}
==25728== 8 bytes in 1 blocks are definitely lost in loss record 2 of 4
==25728==    at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25728==    by 0x405D02: std::unique_ptr<std::__detail::_Executor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> >, std::default_delete<std::__detail::_Executor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> > > > std::__detail::__get_executor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char>, (std::__detail::_RegexExecutorPolicy)0>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, std::vector<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, std::basic_regex<char, std::regex_traits<char> > const&, std::regex_constants::match_flag_type) (in /h/lgb/Development/test/a.out)
==25728==    by 0x405F05: bool std::__detail::__regex_algo_impl<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char>, (std::__detail::_RegexExecutorPolicy)0, true>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, std::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, std::basic_regex<char, std::regex_traits<char> > const&, std::regex_constants::match_flag_type) (in /h/lgb/Development/test/a.out)
==25728==    by 0x401FF5: main (in /h/lgb/Development/test/a.out)
==25728== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:_Znwm
   fun:_ZNSt8__detail14__get_executorIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcELNS_20_RegexExecutorPolicyE0EEESt10unique_ptrINS_9_ExecutorIT_T0_T1_T2_EESt14default_deleteISI_EESE_SE_RSt6vectorIS6_ISE_ESF_ERKSt11basic_regexISG_SH_ENSt15regex_constants15match_flag_typeE
   fun:_ZNSt8__detail17__regex_algo_implIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcELNS_20_RegexExecutorPolicyE0ELb1EEEbT_SC_RSt13match_resultsISC_T0_ERKSt11basic_regexIT1_T2_ENSt15regex_constants15match_flag_typeE
   fun:main
}
==25728== 8 bytes in 1 blocks are definitely lost in loss record 3 of 4
==25728==    at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25728==    by 0x40DA8F: void std::vector<long, std::allocator<long> >::_M_emplace_back_aux<long const&>(long const&) (in /h/lgb/Development/test/a.out)
==25728==    by 0x40E41D: std::__detail::_BFSExecutor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> >::_M_init(__gnu_cxx::__normal_iterator<char const*, std::string>) (in /h/lgb/Development/test/a.out)
==25728==    by 0x405F1C: bool std::__detail::__regex_algo_impl<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char>, (std::__detail::_RegexExecutorPolicy)0, true>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, std::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, std::basic_regex<char, std::regex_traits<char> > const&, std::regex_constants::match_flag_type) (in /h/lgb/Development/test/a.out)
==25728==    by 0x401FF5: main (in /h/lgb/Development/test/a.out)
==25728== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:_Znwm
   fun:_ZNSt6vectorIlSaIlEE19_M_emplace_back_auxIIRKlEEEvDpOT_
   fun:_ZNSt8__detail12_BFSExecutorIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcEE7_M_initES5_
   fun:_ZNSt8__detail17__regex_algo_implIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcELNS_20_RegexExecutorPolicyE0ELb1EEEbT_SC_RSt13match_resultsISC_T0_ERKSt11basic_regexIT1_T2_ENSt15regex_constants15match_flag_typeE
   fun:main
}
==25728== 8 bytes in 1 blocks are definitely lost in loss record 4 of 4
==25728==    at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25728==    by 0x40DA8F: void std::vector<long, std::allocator<long> >::_M_emplace_back_aux<long const&>(long const&) (in /h/lgb/Development/test/a.out)
==25728==    by 0x40EF2D: std::__detail::_BFSExecutor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> >::_M_e_closure() (in /h/lgb/Development/test/a.out)
==25728==    by 0x40F44D: std::__detail::_BFSExecutor<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char> >::_M_main() (in /h/lgb/Development/test/a.out)
==25728==    by 0x405F25: bool std::__detail::__regex_algo_impl<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, std::regex_traits<char>, (std::__detail::_RegexExecutorPolicy)0, true>(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, std::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<std::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, std::basic_regex<char, std::regex_traits<char> > const&, std::regex_constants::match_flag_type) (in /h/lgb/Development/test/a.out)
==25728==    by 0x401FF5: main (in /h/lgb/Development/test/a.out)
==25728== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:_Znwm
   fun:_ZNSt6vectorIlSaIlEE19_M_emplace_back_auxIIRKlEEEvDpOT_
   fun:_ZNSt8__detail12_BFSExecutorIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcEE12_M_e_closureEv
   fun:_ZNSt8__detail12_BFSExecutorIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcEE7_M_mainEv
   fun:_ZNSt8__detail17__regex_algo_implIN9__gnu_cxx17__normal_iteratorIPKcSsEESaISt9sub_matchIS5_EEcSt12regex_traitsIcELNS_20_RegexExecutorPolicyE0ELb1EEEbT_SC_RSt13match_resultsISC_T0_ERKSt11basic_regexIT1_T2_ENSt15regex_constants15match_flag_typeE
   fun:main
}
==25728== LEAK SUMMARY:
==25728==    definitely lost: 32 bytes in 4 blocks
==25728==    indirectly lost: 0 bytes in 0 blocks
==25728==      possibly lost: 0 bytes in 0 blocks
==25728==    still reachable: 0 bytes in 0 blocks
==25728==         suppressed: 0 bytes in 0 blocks
==25728== 
==25728== For counts of detected and suppressed errors, rerun with: -v
==25728== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 2)

-- 
	Lgb

Re: memory leak in regex - 4.9.0

[Jonathan Wakely]

On 15 October 2013 10:42, Lars Gullik Bjønnes wrote:
>
> Hi,
>
> I have something that certainly looks like a memory leak.

Thanks, I'm looking into it ...

Re: memory leak in regex - 4.9.0

[Jonathan Wakely]

On 15 October 2013 10:47, Jonathan Wakely wrote:
> On 15 October 2013 10:42, Lars Gullik Bjønnes wrote:
>>
>> Hi,
>>
>> I have something that certainly looks like a memory leak.
>
> Thanks, I'm looking into it ...

I can reproduce it but it isn't obvious where it's coming from, could
you please report it to Bugzilla?

Re: memory leak in regex - 4.9.0

[Lars Gullik Bjønnes]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

| On 15 October 2013 10:47, Jonathan Wakely wrote:
>> On 15 October 2013 10:42, Lars Gullik Bjønnes wrote:
>>>
>>> Hi,
>>>
>>> I have something that certainly looks like a memory leak.
>>
>> Thanks, I'm looking into it ...
>
| I can reproduce it but it isn't obvious where it's coming from, could
| you please report it to Bugzilla?

Sure.

Bug 58737

-- 
	Lgb