Why memory leaks?

Discussion in 'C++' started by Billy Patton, May 26, 2005.

  1. Billy Patton

    Billy Patton Guest

    I have this test code:

    {
    String s("123");
    OK(s.Len() == 3);


    OK is a define to print __LINE__ and increment a test_count and a failure count

    String is built using std::string as the memory namager for the string.

    I have the following method:
    This one produces no errors with purify.
    size_t String::Len(void)
    {
    if (str.empty()) return 0;
    return strlen(str.c_str());
    // return str.size();
    }

    size_t String::Len(void)
    {
    return str.size();
    }

    THe routine above produces the one above. The folowing is from purify:
    Finished test ( 1 error, 0 leaked bytes)
    Purify instrumented SunOS/32/test (pid 15865 at Thu May 26 07:32:17 2005)
    UMR: Uninitialized memory read
    This is occurring while in:
    __big_float_times_power [libc.a]
    __binary_to_decimal_fraction [libc.a]
    _unpacked_to_decimal_two [libc.a]
    __k_double_to_decimal [libc.a]
    double_to_decimal [libc.a]
    econvert [libc.a]
    Reading 2 bytes from 0xffbedfda on the stack.
    Address 0xffbedfda is 1086 bytes below frame pointer in function
    __k_double_to_decimal.
    Current file descriptors in use: 5
    Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)
    Purify Heap Analysis (combining suppressed and unsuppressed blocks)
    Blocks Bytes
    Leaked 0 0
    Potentially Leaked 1 8200
    In-Use 0 0
    ----------------------------------------
    Total Allocated 1 8200
    Program exited with status code 0.
    * Basic memory usage (including Purify overhead):
    2566822 code
    1947676 data/bss
    16388 heap (peak use)
    3040 stack


    It appears that std::string::size is causing the error.

    I use gcc 3.4.2 on a solaris 8 box.
    purify.sol.2002a.06.00
    Since IBM bought Purify we don't see updates/new releases

    ___ _ ____ ___ __ __
    / _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
    / _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
    /____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
    /___/
    Texas Instruments ASIC Circuit Design Methodology Group
    Dallas, Texas, 214-480-4455,
    Billy Patton, May 26, 2005
    #1
    1. Advertising

  2. Billy Patton

    Billy Patton Guest

    On Thu, 26 May 2005, Billy Patton wrote:

    > I have this test code:
    >
    > {
    > String s("123");
    > OK(s.Len() == 3);
    >
    >
    > OK is a define to print __LINE__ and increment a test_count and a failure
    > count
    >
    > String is built using std::string as the memory namager for the string.
    >
    > I have the following method:
    > This one produces no errors with purify.
    > size_t String::Len(void)
    > {
    > if (str.empty()) return 0;
    > return strlen(str.c_str());
    > // return str.size();
    > }
    >
    > size_t String::Len(void)
    > {
    > return str.size();
    > }
    >
    > THe routine above produces the one above. The folowing is from purify:
    > Finished test ( 1 error, 0 leaked bytes)
    > Purify instrumented SunOS/32/test (pid 15865 at Thu May 26 07:32:17
    > 2005)
    > UMR: Uninitialized memory read
    > This is occurring while in:
    > __big_float_times_power [libc.a]
    > __binary_to_decimal_fraction [libc.a]
    > _unpacked_to_decimal_two [libc.a]
    > __k_double_to_decimal [libc.a]
    > double_to_decimal [libc.a]
    > econvert [libc.a]
    > Reading 2 bytes from 0xffbedfda on the stack.
    > Address 0xffbedfda is 1086 bytes below frame pointer in function
    > __k_double_to_decimal.
    > Current file descriptors in use: 5
    > Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)
    > Purify Heap Analysis (combining suppressed and unsuppressed blocks)
    > Blocks Bytes
    > Leaked 0 0
    > Potentially Leaked 1 8200
    > In-Use 0 0
    > ----------------------------------------
    > Total Allocated 1 8200
    > Program exited with status code 0.
    > * Basic memory usage (including Purify overhead):
    > 2566822 code
    > 1947676 data/bss
    > 16388 heap (peak use)
    > 3040 stack
    >
    >
    > It appears that std::string::size is causing the error.
    >
    > I use gcc 3.4.2 on a solaris 8 box.
    > purify.sol.2002a.06.00
    > Since IBM bought Purify we don't see updates/new releases
    >
    > ___ _ ____ ___ __ __
    > / _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
    > / _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
    > /____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
    > /___/ Texas Instruments ASIC Circuit Design Methodology Group
    > Dallas, Texas, 214-480-4455,
    >


    I tried this code on the Linux box with
    PurifyPlus.2003a.06.13/i386_linux2/bin/purify
    and had no leaks?????
    #include <iostream>
    #include <string>

    using namespace std;

    int main(void)
    {
    std::string s("abc");
    size_t len = s.size();
    cout << "len = " << len << "\n";
    return 0;
    }


    ___ _ ____ ___ __ __
    / _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
    / _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
    /____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
    /___/
    Texas Instruments ASIC Circuit Design Methodology Group
    Dallas, Texas, 214-480-4455,
    Billy Patton, May 26, 2005
    #2
    1. Advertising

  3. Billy Patton

    Billy Patton Guest

    On Thu, 26 May 2005, Billy Patton wrote:

    > On Thu, 26 May 2005, Billy Patton wrote:
    >
    >> I have this test code:
    >>
    >> {
    >> String s("123");
    >> OK(s.Len() == 3);
    >>
    >>
    >> OK is a define to print __LINE__ and increment a test_count and a failure
    >> count
    >>
    >> String is built using std::string as the memory namager for the string.
    >>
    >> I have the following method:
    >> This one produces no errors with purify.
    >> size_t String::Len(void)
    >> {
    >> if (str.empty()) return 0;
    >> return strlen(str.c_str());
    >> // return str.size();
    >> }
    >>
    >> size_t String::Len(void)
    >> {
    >> return str.size();
    >> }
    >>
    >> THe routine above produces the one above. The folowing is from purify:
    >> Finished test ( 1 error, 0 leaked bytes)
    >> Purify instrumented SunOS/32/test (pid 15865 at Thu May 26 07:32:17
    >> 2005)
    >> UMR: Uninitialized memory read
    >> This is occurring while in:
    >> __big_float_times_power [libc.a]
    >> __binary_to_decimal_fraction [libc.a]
    >> _unpacked_to_decimal_two [libc.a]
    >> __k_double_to_decimal [libc.a]
    >> double_to_decimal [libc.a]
    >> econvert [libc.a]
    >> Reading 2 bytes from 0xffbedfda on the stack.
    >> Address 0xffbedfda is 1086 bytes below frame pointer in function
    >> __k_double_to_decimal.
    >> Current file descriptors in use: 5
    >> Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)
    >> Purify Heap Analysis (combining suppressed and unsuppressed blocks)
    >> Blocks Bytes
    >> Leaked 0 0
    >> Potentially Leaked 1 8200
    >> In-Use 0 0
    >> ----------------------------------------
    >> Total Allocated 1 8200
    >> Program exited with status code 0.
    >> * Basic memory usage (including Purify overhead):
    >> 2566822 code
    >> 1947676 data/bss
    >> 16388 heap (peak use)
    >> 3040 stack
    >>
    >>
    >> It appears that std::string::size is causing the error.
    >>
    >> I use gcc 3.4.2 on a solaris 8 box.
    >> purify.sol.2002a.06.00
    >> Since IBM bought Purify we don't see updates/new releases
    >>
    >> ___ _ ____ ___ __ __
    >> / _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
    >> / _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
    >> /____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
    >> /___/ Texas Instruments ASIC Circuit Design Methodology Group
    >> Dallas, Texas, 214-480-4455,
    >>

    >
    > I tried this code on the Linux box with
    > PurifyPlus.2003a.06.13/i386_linux2/bin/purify
    > and had no leaks?????
    > #include <iostream>
    > #include <string>
    >
    > using namespace std;
    >
    > int main(void)
    > {
    > std::string s("abc");
    > size_t len = s.size();
    > cout << "len = " << len << "\n";
    > return 0;
    > }
    >
    >
    > ___ _ ____ ___ __ __
    > / _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
    > / _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
    > /____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
    > /___/ Texas Instruments ASIC Circuit Design Methodology Group
    > Dallas, Texas, 214-480-4455,
    >


    Must have been the older oversion of Purify on solaris. Ran with the
    PurifyPlus 2003 version on Linux and leak went away.

    As that great poet/philosopher Alf one said "go figure" :)


    ___ _ ____ ___ __ __
    / _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
    / _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
    /____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
    /___/
    Texas Instruments ASIC Circuit Design Methodology Group
    Dallas, Texas, 214-480-4455,
    Billy Patton, May 26, 2005
    #3
  4. Billy Patton wrote:
    > On Thu, 26 May 2005, Billy Patton wrote:
    >
    >> On Thu, 26 May 2005, Billy Patton wrote:
    >>
    >>> I have this test code:
    >>> [...]


    Do you think you could at least trim your *own* signatures when you reply
    to yourself?

    And, please, keep in mind that Purify is not topical here. Talk to their
    Tech Support about any issues you have with that product. This is
    a _language_ newsgroup, please limit your posts to _language_ topics.

    V
    Victor Bazarov, May 26, 2005
    #4
  5. Billy Patton

    Mark P Guest

    Billy Patton wrote:
    > I have this test code:
    >
    > {
    > String s("123");
    > OK(s.Len() == 3);
    >
    >

    [snip]

    It's fairly well known that STL classes and purify sometimes interact
    badly and the latter can be confused by the former. In part this is
    because STL objects may do nonobvious things with their memory,
    ostensibly for optimization purposes, such as not freeing memory
    promptly and reserving it for later allocations. You should look at the
    purify website as I believe this is discussed there.
    Mark P, May 26, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ASP.Confused

    ASP.NET - Detecting memory leaks

    ASP.Confused, Jul 16, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    2,741
    Marina
    Jul 16, 2004
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    880
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,843
    Smokey Grindel
    Dec 2, 2006
  4. Sven C. Koehler
    Replies:
    6
    Views:
    110
    Nobuyoshi Nakada
    Aug 20, 2008
  5. Replies:
    4
    Views:
    121
Loading...

Share This Page