std::string causing memory leaks - c++

Question

I am running into a situation where my application is having memory leaks. After running valgrind, it looks as if I am getting a memory leak related to a std::string:
==20274== 34 bytes in 1 blocks are definitely lost in loss record 34 of 140
==20274== at 0x4C29DB5: operator new(unsigned long) (vg_replace_malloc.c:332)
==20274== by 0x7F843C8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.13)
==20274== by 0x7F84DE4: ??? (in /usr/lib64/libstdc++.so.6.0.13)
==20274== by 0x7F84F32: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.13)
==20274== by 0xA50CC71: __static_initialization_and_destruction_0(int, int) (filename.cpp:22)
==20274== by 0xA50D03F: _GLOBAL__sub_I_filename.cpp (filename.cpp:112)
==20274== by 0x400E9CE: _dl_init (in /lib64/ld-2.12.so)
==20274== by 0x4000B69: ??? (in /lib64/ld-2.12.so)
The code in question is:
in filename.h:
extern std::string aString;
in filename.cpp:
std::string aString = "a string";
Also worth note, this is in a separate namespace i.e.
namespace aNamespace {
//...
std::string aString; // in extern in .h
//...
}
Every place in code, it is (of course) referenced as:
aNamespace::aString;
And, from what I can tell, it is never reset, and is used either as a constant reference, or to initialize another string.
Can there ever be a situation where std::string would give memory leaks?
edit:
A related portion of the valgrind output:
==20274== by 0x400EFBB: _dl_fini (in /lib64/ld-2.12.so)
==20274== by 0x88DAA01: exit (in /lib64/libc-2.12.so)
==20274== by 0x88C3D26: (below main) (in /lib64/libc-2.12.so)
Is this making an exit call? Is it the standard exit(0)?

Answer 1

Valgrind produces this kind of messages if on program termination there's still some heap-allocated memory, but no variable holds a pointer to.
std::string allocates memory in it's constructor to provide storage for chars. Destructor should free memory back.
My guess is that application is terminated using exit(0) or so. In this case stack does not unwind, and no destructors are called.