Board index » cppbuilder » delete[] count differs from new[] count

delete[] count differs from new[] count

This is a piece from a BCB5 codeguard *.cgl file:

  delete (35 times)
  ...
  realloc (11 times)
  memcpy (11018 times)
  delete[] (189 times)
  free (46539 times)
  new[] (201 times)
  new (40 times)
  calloc (4 times)
  malloc (46534 times)

Wondered why the number of new[]'s (201 times) differs from
delete[]'s (189 times).

Codeguard did not report errors in that session.

The same applies to new and delete.

I thought they should be the same. How is this possible ?

Hans.

 

Re:delete[] count differs from new[] count


Quote
Hans Galema <j.m.galema.dontuset...@maartens.nl> writes:
> This is a piece from a BCB5 codeguard *.cgl file:

>   delete (35 times)
>   ...
>   realloc (11 times)
>   memcpy (11018 times)
>   delete[] (189 times)
>   free (46539 times)
>   new[] (201 times)
>   new (40 times)
>   calloc (4 times)
>   malloc (46534 times)

> Wondered why the number of new[]'s (201 times) differs from
> delete[]'s (189 times).

Hmmmm, it looks like your program is calling realloc on memory that
was allocated with new[].  There are 11 calls to realloc, and
coincidently, there are 11 too-few calls to delete[].

That's a serious memory bug, and should never be done.  Mixing realloc
with any of the C++ allocators is undefined.

It also looks like in some cases delete is not being called for each
associated new expression, as you have 40 new-s, and only 35
delete-s.  

Quote
> Codeguard did not report errors in that session.

Perhaps codeguard is not perfect.

Quote
> The same applies to new and delete.
> I thought they should be the same. How is this possible ?

I'm not sure, I don't know CG very well.  WHEN does it make that
report?  At the end of "main" or after all of the global variables
have been destroyed?  Maybe it's taking the "snapshot" of your memory
before the program is completely done running.  I don't know.

Can you shorten the code that it requires to get such a report, and
post it?

--
Chris(TeamB);

Re:delete[] count differs from new[] count


Quote
"Chris Uzdavinis [TeamB]" wrote:
> Hmmmm, it looks like your program is calling realloc on memory that
> was allocated with new[].  There are 11 calls to realloc, and
> coincidently, there are 11 too-few calls to delete[].
> That's a serious memory bug, and should never be done.  Mixing realloc
> with any of the C++ allocators is undefined.

My guess is it is happening in the RTL itself (and so I hope is safe!!)
I have seen the similar reports on our own code, and we never use
realloc!!

Quote
> Perhaps codeguard is not perfect.

Of course, that is always a possibility too <g>

--
AlisdairM
Team Thai Kingdom

Re:delete[] count differs from new[] count


Quote
Alisdair Meredith <alisdair.mered...@uk.renaultf1.com> writes:
> "Chris Uzdavinis [TeamB]" wrote:

> > Hmmmm, it looks like your program is calling realloc on memory that
> > was allocated with new[].  There are 11 calls to realloc, and
> > coincidently, there are 11 too-few calls to delete[].

> > That's a serious memory bug, and should never be done.  Mixing realloc
> > with any of the C++ allocators is undefined.

> My guess is it is happening in the RTL itself (and so I hope is safe!!)
> I have seen the similar reports on our own code, and we never use
> realloc!!

If the RTL is doing it then that is not a problem.  But if user-code
does it it IS a problem.  (The RTL is allowed to make
compiler/platform specific calls, since it is intimately related to
the compiler.  But user code is completely detached, and should not
depend on these things becuase it'll almost always pass testing but
fail at the worst possible moment.)

--
Chris(TeamB);

Re:delete[] count differs from new[] count


Alisdair Meredith,

Quote
> > Perhaps codeguard is not perfect.

> Of course, that is always a possibility too <g>

Gasp! You dare to impugn the marvelous Code Guard? Heretic! May He
rise up and strike you down :)
--
Andrue Cope
[Bicester, UK]

Re:delete[] count differs from new[] count


Quote
Andrue Cope wrote:
> Gasp! You dare to impugn the marvelous Code Guard? Heretic! May He
> rise up and strike you down :)

Hey, he impugns me often enough ;? )

--
AlisdairM
Team Thai Kingdom

Re:delete[] count differs from new[] count


Quote
Chris Uzdavinis [TeamB] wrote:
> Hans Galema <j.m.galema.dontuset...@maartens.nl> writes:
>>Wondered why the number of new[]'s (201 times) differs from
>>delete[]'s (189 times).

> Hmmmm, it looks like your program is calling realloc on memory that
> was allocated with new[].  There are 11 calls to realloc, and
> coincidently, there are 11 too-few calls to delete[].

Accidentally that's 12.

Quote
> That's a serious memory bug, and should never be done.  Mixing realloc
> with any of the C++ allocators is undefined.

I try not to mix malloc with delete and new with free. But
codeguard warns for that as far as I know.

Quote
> I'm not sure, I don't know CG very well.  WHEN does it make that
> report?  At the end of "main" or after all of the global variables
> have been destroyed?  
> Maybe it's taking the "snapshot" of your memory
> before the program is completely done running.  I don't know.

Don't know either.

Quote
> Can you shorten the code that it requires to get such a report, and
> post it?

No, as the program is way to big. But I think that Alisdair is right
as an empty form program does the same.

Thanks for the reply. I don't bother anymore.

Hans.

Re:delete[] count differs from new[] count


Quote
Alisdair Meredith wrote:
> My guess is it is happening in the RTL itself (and so I hope is safe!!)
> I have seen the similar reports on our own code, and we never use
> realloc!!

Now I ade a program with only one TForm without any code.

The result:

Functions called:
  delete (35 times)
  SysFreeMem (276 times)
  SysGetMem (276 times)
  realloc (1 times)
  memcpy (1 times)
  delete[] (2 times)
  free (24 times)
  new[] (14 times)
  new (40 times)
  calloc (4 times)
  malloc (19 times)
Resource types used:
  object array (14 allocs, 13 max)
  object (40 allocs, 28 max)
  memory block (300 allocs, 226 max)

Here the amounts are not equal too.

new[] - delete[] = 40 - 2 = 38.

That's much more than the -big-program in my original post.

I think you are right with that it is in the RTL, but there is more
when the 38 changes.

Thanks for the reply and the info.

Hans.

Re:delete[] count differs from new[] count


Alisdair Meredith,

Quote
> > Gasp! You dare to impugn the marvelous Code Guard? Heretic! May He
> > rise up and strike you down :)

> Hey, he impugns me often enough ;? )

And in such a polite and friendly way 'n' all :)

Borland are going to be putting it into Delphi supposedly and I can
forsee tears before bedtime from those poor delicate Delphi types...
--
Andrue Cope
[Bicester, UK]

Re:delete[] count differs from new[] count


Is there a runtime way to see the amount of memory currently allocated by
new[]?

Tony

Quote
Hans Galema <j.m.galema.dontuset...@maartens.nl> wrote in message

news:3ec8ee3e@newsgroups.borland.com...
Quote
> Chris Uzdavinis [TeamB] wrote:
> > Hans Galema <j.m.galema.dontuset...@maartens.nl> writes:

> >>Wondered why the number of new[]'s (201 times) differs from
> >>delete[]'s (189 times).

> > Hmmmm, it looks like your program is calling realloc on memory that
> > was allocated with new[].  There are 11 calls to realloc, and
> > coincidently, there are 11 too-few calls to delete[].

> Accidentally that's 12.

> > That's a serious memory bug, and should never be done.  Mixing realloc
> > with any of the C++ allocators is undefined.

> I try not to mix malloc with delete and new with free. But
> codeguard warns for that as far as I know.

> > I'm not sure, I don't know CG very well.  WHEN does it make that
> > report?  At the end of "main" or after all of the global variables
> > have been destroyed?
> > Maybe it's taking the "snapshot" of your memory
> > before the program is completely done running.  I don't know.

> Don't know either.

> > Can you shorten the code that it requires to get such a report, and
> > post it?

> No, as the program is way to big. But I think that Alisdair is right
> as an empty form program does the same.

> Thanks for the reply. I don't bother anymore.

> Hans.

Re:delete[] count differs from new[] count


Quote
A Whitesell wrote:
> Is there a runtime way to see the amount of memory currently allocated by
> new[]?

Sorry, don't know.

Hans.

Re:delete[] count differs from new[] count


There is no facility to do that in the runtime library.  You could try
writing your own new and adding up the allocations and keep the sum in a
global variable that you can watch in the de{*word*81}.

.  Ed

Quote
> A Whitesell wrote in message
> news:3ececc76@newsgroups.borland.com...
> Is there a runtime way to see the amount of memory
> currently allocated by new[]?

Other Threads