stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-587) purify reports memory leak from __rw_tmpbuf in 20.temp.buffer.mt
Date Tue, 23 Oct 2007 20:15:50 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537122
] 

Travis Vitek commented on STDCXX-587:
-------------------------------------

That option was not considered because it doesn't actually eliminate the leak. :P Consider
the case where rw_opt_nloops is 1 and there are 4 threads. The switch for the last iteration
for each thread will be '((rw_opt_nloops*8-1) + targs->threadno_) % 8' for each thread
so we have

thread 0: 7 + 0 % 8 => 7
thread 1: 7 + 1 % 8 => 0
thread 2: 7 + 2 % 8 => 1
thread 3: 7 + 3 % 8 => 2

So on the last iteration, threads 1, 2 and 3 will allocate memory. Not good. There is that
and the fact that the number of loops executed would be 8x what the user requested with the
--nloops command line option.

I also considered allocating and deallocating from the same case block, but that has the disadvantage
that it doesn't test multiple outstanding allocations from the same thread.



> purify reports memory leak from __rw_tmpbuf in 20.temp.buffer.mt
> ----------------------------------------------------------------
>
>                 Key: STDCXX-587
>                 URL: https://issues.apache.org/jira/browse/STDCXX-587
>             Project: C++ Standard Library
>          Issue Type: Improvement
>          Components: Tests
>            Reporter: Travis Vitek
>            Priority: Minor
>             Fix For: 4.2.1
>
>         Attachments: stdcxx-587.patch
>
>
> Each test thread iterates some number of times switching on a counter. If the last iteration
runs one of the allocation functions, the temporary buffer will not be deallocated when the
thread exits.
> Purify: Searching for all memory leaks...
> Memory leaked: 42 bytes (6.98%); potentially leaked: 0 bytes (0%)
> MLK: 24 bytes leaked at 0x81089d0
>   * This memory was allocated from:
>     malloc         [rtlib.o]
>     operator new(unsigned) [libstd15d.so]
>     __rw::__rw_allocate(unsigned, int) [memory.cpp:53]
>     __rw_tmpbuf    [tmpbuf.cpp:115]
>     std::pair<long long*, int > std::get_temporary_buffer<long long, int >(int,
long long*) [_rawiter.h:138]
>     std::pair<long long*, int > std::get_temporary_buffer<long long>(int)
[_rawiter.h:153]
> MLK: 18 bytes leaked at 0x8108a38
>   * This memory was allocated from:
>     malloc         [rtlib.o]
>     operator new(unsigned) [libstd15d.so]
>     __rw::__rw_allocate(unsigned, int) [memory.cpp:53]
>     __rw_tmpbuf    [tmpbuf.cpp:115]
>     std::pair<short*, int > std::get_temporary_buffer<short, int >(int, short*)
[_rawiter.h:138]
>     std::pair<short*, int > std::get_temporary_buffer<short>(int) [_rawiter.h:153]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message