Re: An STL string leak
Thanks Joe, please see below comments...
On Jul 5, 8:49 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below...
On Mon, 5 Jul 2010 08:13:29 -0700 (PDT), dushkin <talt...@gmail.com> wrot=
e:
More important information...
The original string is created as:
COleDateTime now=
= COleDateTime::GetCurrentTime();
CString sFormat;
sFormat.LoadStri=
ng(IDS_NOW_TIME_FORMAT);
now.Format(sFormat);
and I cast it to string as (LPCTSTR)sNow.
****
When do you cast it, and why?
I cast the CString sNow to a string object. This is in order to pass
it to an object member which requires a string object in its
constructor.
But I also tried to initiate this string member with the current time
inside the constructor - without passing it to the ctor and without
casting, and the same leak occurred.
Note that this will not affect the "leak" issue. The leak issue is bec=
ause the object is
not being deleted.
Are you sure the delete operator is actually being called?
I am sure the I call the delete of this object, but I am afraid that I
miss something..
The pointer address that we see in the leak message is of an inner
pointer of the string object which is a member of the object which I
delete.
As I tried to explain in my first post, the object that I delete is of
type CB and it has the string member.
When it is deleted, the string leaks. And in more detail: there is
some _Bx->_Ptr of this string which leaks (according to the address in
the leak message)
By the way, I also tried
time_t tm;
time(&tm);
string sNow = FormatTime(tm);
string FormatTime( const time_t time )
{
struct tm ts;
char szBuffer[80] = "DD-MM-YY HH:MM:SS";
errno_t err = localtime_s(&ts,&time);
if (err)
{
}
else
{
// Format the time
strftime(szBuffer, sizeof(szBuffer), "%d-%b-%Y %X%p", &ts);
}
return szBuffer;
}
which spared me from using casting and the same result occurred. This
is the code that I use now inside CB ctor to initialize the string
member.
If I wanted to track this down, I'd put a breakpoint where the delete is =
invoked, then I'd
do a lot of instruction-level single stepping to make sure that the objec=
t was actually
being deleted.
I'm curious why you titled this an "STL" string leak, since I do not see =
a single instance
of std::string anywhere in the code.
I hope it is clearer now...
In addition, it may be a leak (odd though it may be) in the COleDateTime:=
:Format handler;
so you need to check the CString that is returned, and look at its data p=
ointer. Then
compare that data pointer to the one that is claimed as a leak. If the=
y are not the same,
then it is not that string. Now the mystery is: where did that string =
come from.
Note that in the leak message, there is a {count} given. If, when runn=
ing this program,
you can exactly replicate this message with the same {count} (which ideal=
ly should happen
if you do exactly thesame things in exactly the same order), then you can=
tell the
storage allocator to break on that allocation sequence number, and find o=
ut who really
allocated that string.
I note that the location of the allocation is not given as strcore.cpp, w=
hich would be
true if this really were the CString. So it looks like it is being all=
ocated from
somewhere else.
So it is probably really not the CString...
If you write a file which does not come from the MFC wizards, make sure y=
ou find the
#define new DEBUG_NEW
line in some other file and copy it, along with all its conditionals, to =
your own file;
this will allow allocation tracking to be more effective. You may also=
need to copy the
this_file definition.
I added
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif
to all of my files now. But how should it help me? because at least at
the leak message I don't see any extra information.
joe
****
****
If instead all the above I will put
CString sNow = "a"
and then I'll cast - there is no leak!
Thanks!
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm