How can I determine the size of the heap

[Pep]

I have a problem I need to solve which looks like memory exhaustion.
Is there a function that I can use in c++ to determine the size of the
heap before and after a allocation?

The C++ code is running on linux and freeBSD.

The actual library I am interfacing with uses malloc and i have no
control over it so I need to see the state of the heap after each use
of the libraries allocation functions.

TIA.

 

[Ian Collins]

I have a problem I need to solve which looks like memory exhaustion.
Is there a function that I can use in c++ to determine the size of the
heap before and after a allocation?

The C++ code is running on linux and freeBSD.

The actual library I am interfacing with uses malloc and i have no
control over it so I need to see the state of the heap after each use
of the libraries allocation functions.

Not in standard C++, you could roll your own new/delete and keep stats.
You could also track the memory allocated to the process.

 

[Pep]

Not in standard C++, you could roll your own new/delete and keep stats.
You could also track the memory allocated to the process.

As I thought

 

[Michiel.Salters]

I have a problem I need to solve which looks like memory exhaustion.
Is there a function that I can use in c++ to determine the size of the
heap before and after a allocation?

No, because 1. there may not be such a size and 2. even if there were,
there is no guarantee that any change to it is due to actions of the
program
itself.

E.g. if "the heap" is managed directly by the OS, its size might change
due
to other programs, and it might use lazy bookkeeping. (lazy: when
memory is
released, it's put on a quick-recycle list instead of being marked as
free in the
heap.)

Michiel.

 

[Ron Natalie]

Not in standard C++, you could roll your own new/delete and keep stats.
You could also track the memory allocated to the process.

And that still doesn't help you much if you have things that allocate
memory outside of new/delete. You need help outside the C++ language.
If all you want to know is the heap size, most UNIX variants use a call
to sbrk() that can be used to probe where the heap is. Many better
tools are also available. Google: FreeBSD Heap Debugging

 

[Pep]

No, because 1. there may not be such a size and 2. even if there were,
there is no guarantee that any change to it is due to actions of the
program
itself.

E.g. if "the heap" is managed directly by the OS, its size might change
due
to other programs, and it might use lazy bookkeeping. (lazy: when
memory is
released, it's put on a quick-recycle list instead of being marked as
free in the
heap.)

Michiel.

Thanks for the explanation. I was just whistling in the wind for a
quick tool to help work out what was going on, as it turns out now I
have been given more project time to deprecate the old C library and
replace with a good C++ library which will be using new/delete and
exceptions

 

[Pep]

And that still doesn't help you much if you have things that allocate
memory outside of new/delete. You need help outside the C++ language.
If all you want to know is the heap size, most UNIX variants use a call
to sbrk() that can be used to probe where the heap is. Many better
tools are also available. Google: FreeBSD Heap Debugging

I see your point and thanks for the info. I will be replacing the old
C code for better C++ code.

 

[Greg Comeau]

Thanks for the explanation. I was just whistling in the wind for a
quick tool to help work out what was going on, as it turns out now I
have been given more project time to deprecate the old C library and
replace with a good C++ library which will be using new/delete and
exceptions

Don't go too hog wild. That is, using malloc/free or even
new/delete may be programming at the wrong level of abstraction,
so give it some deep thought, even if you are doing lib centric code,
especially if you are thinking of just replacing one with the other.
This statement is not to say that it won't work or that it's the
wrong thing, just that you may have better choices available to you,
and so "just" consider alternatives first.

 

[Greg Comeau]

I see your point and thanks for the info. I will be replacing the old
C code for better C++ code.

I'm unable to get to the beginning of this thread, but doing 1:1
replacements is not always necessarily better. As per my other
post, consider things in a more grander scale, otherwise you
may be piecemealing a mess. (And again, a mess doesn't have to
be the result, but just be cautious and know why you're changing
one thing for the other, and what any higher level implication can
and do and will mean if they are chosen instead).

 

[Pep]

I'm unable to get to the beginning of this thread, but doing 1:1
replacements is not always necessarily better. As per my other
post, consider things in a more grander scale, otherwise you
may be piecemealing a mess. (And again, a mess doesn't have to
be the result, but just be cautious and know why you're changing
one thing for the other, and what any higher level implication can
and do and will mean if they are chosen instead).
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

I agree that replacement for the sake of it is not always the best
choice but in this case the old C library is not the best code and does
not perform even the most basic of validation for things like the
pointer being safe before it frees the memory or even that it got the
memory it asked for.

This is a critical library and has been traced as the root cause of a
number of problems in the code so it is best in this case to replace
rather than try to re-engineer it.

 

[Greg Comeau]

I agree that replacement for the sake of it is not always the best
choice but in this case the old C library is not the best code and does
not perform even the most basic of validation for things like the
pointer being safe before it frees the memory or even that it got the
memory it asked for.

This is a critical library and has been traced as the root cause of a
number of problems in the code so it is best in this case to replace
rather than try to re-engineer it.

I can't but help feeling that you are blaming the C library.
(I don't think you are, but it could sound that way.)
Although I agree there are limitations here, I think the operative
word in your post is re-enginnering because probably the _user code_
not the C lib itself was not written to deal with the tradeoffs of
the C lib. I am therefore left to conclude that although using
new/delete may bring things up a notch or two (nothing wrong with
that in and of itself at first glace) that any underlying problems
with the user code now will still exist upon such changes.
This is not such say some problems won't be uncovered in such a process,
just that it's probably at too low level a "fix" and usually the
result is that it won't possess the "magic" necessary in the grand
scheme of things. I am not saying not to try/do this, just that
I believe your underlying problem is greater than what I'm understanding
you want out of this fix, even sight unseen. Also, there may be
additional ways to reengineer the lib while still providing the
same interfaces, although that could be messy too.