Re: Leakage from initialization of pair<..., string>

[Wu Yongwei <adah at netstd dot com>]

Maybe you are willing to try this?

#include <memory>
#include <new>
#include <string>
#include <stdio.h>

typedef std::pair<unsigned, std::string> uint_str_t;
std::pair<unsigned, std::string>  g_key_id_name_pairs[] = {
    uint_str_t(64, "@"),
    uint_str_t(65, "A"),
    uint_str_t(66, "B")
};

static size_t alloc_cnt;

void* operator new(size_t size) throw(std::bad_alloc)
{
    printf("operator new is called \n");
    void* p = malloc(size);
    if (p == NULL)
        throw std::bad_alloc();
    alloc_cnt++;
    return p;
}

void operator delete(void* p) throw()
{
    printf("operator delete is called \n");
    if (p == NULL)
        return;
    alloc_cnt--;
    if (alloc_cnt == 0)
        printf("All memory released \n");
    else
        printf("%u allocations to be released \n", alloc_cnt);
}

int main()
{
}

On my box it will print three lines of "operator new is called" (w/
GLIBCPP_FORCE_NEW=1; only one line of "operator new..." if this
enviroment variable is unset), but nothing more. This should be easier
to reproduce.

Best regards,

Yongwei

--- Original Message from Benjamin Kosnik ---

I'm unable to reproduce this, on x86/linux. I've looked at this with
valgrind, with and without GLIBCXX_FORCE_NEW, and see no leaks.

I don't see any bits that impact string that would be different between
the two configs, but perhaps I'm wrong.

-benjamin