Debugging memory leaks

[fmassei]

Hello!
I made a short piece of code that I find very useful for debugging,
and I wanted to ask you if it is correct, somehow acceptable or if I
simply reinvented the wheel.
To deal with some bad bugs caused by memory leaks I ended up with this
simple solution: I made one header file that, when included, replaces
the malloc/calloc/realloc/free functions with some other functions
that do the actual job and insert (or remove) the pointers to the
allocated memory in a list. This way I can catch many errors as double
frees, allocations of zero size, or missing calls to free.
Obviously it works only when a given #define is set (NDEBUG, in my
case).
What do you think about it?
Thank you in advance!
(If you want to see the code I wrote a little page here:
http://technicalinsanity.org/out/simplegc/index.html)

[Antoninus Twink]

On 16 Oct 2008 at 20:38, fm*****@gmail.c om wrote:

I was also wondering why the few times I asked something in clc (about
reentrant/thread-safe functions) everybody told me that it was not a
*standard c* related question, while this time quite everybody told me
to use *implementation defined* solutions. Funny!

Of course all these questions are perfectly on-topic in clc.

However, many people here are pursuing a political agenda - they want to
turn the group into a narrow discussion of ISO C, rather than all C. For
this reason, they will refuse to answer your questions, complain
vociferously, and quite possibly insult you into the bargain.

As they won't provide you with any help, the best thing to do is just to
ignore them.

[jameskuyper]

fmas...@gmail.c om wrote:

Hello. Even if no one cares, I wanted to let the people who gave me
positive inputs know that I changed my code according to their good
suggestions.
I was also wondering why the few times I asked something in clc (about
reentrant/thread-safe functions) everybody told me that it was not a
*standard c* related question, while this time quite everybody told me
to use *implementation defined* solutions. Funny! Probably I should
swap my questions somehow, next time.

The only useful C answer to the thread-safe issue was to re-direct you
to forums more appropriate forum for such discussions, since the C
standard doesn't say anthing about threads.

The standard says a lot of things that are relevant to malloc()/
free(), and the feasibility of either wrapping them or replacing them.
Wrapping them is perfectly feasible, but replacing them necessarily
involves undefined behavior. Even explaining the fact that the
behavior is undefined, is more on-topic here than anything to do with
threads, because the C standard doesn't even explicitly say that the
behavior of threaded programs is undefined - the issue isn't discussed
at all.

[Richard]

fm*****@gmail.c om writes:

Hello. Even if no one cares, I wanted to let the people who gave me
positive inputs know that I changed my code according to their good
suggestions.
I was also wondering why the few times I asked something in clc (about
reentrant/thread-safe functions) everybody told me that it was not a
*standard c* related question, while this time quite everybody told me
to use *implementation defined* solutions. Funny! Probably I should
swap my questions somehow, next time.

Because there is a small clique of noisy regulars who want to limit. You
are with them or against the. See the Soduku thread as a great example
of regs purposely misunderstandin g basic scope issues to win points. All
of a sudden Bwian is allowed to not be specific and everyone understands
his unwritten meaning and in addition we have the meaning of extern
being redefined. You could not make it up.

[Antoninus Twink]

On 16 Oct 2008 at 21:20, ja*********@ver izon.net wrote:

The only useful C answer to the thread-safe issue was to re-direct you
to forums more appropriate forum for such discussions, since the C
standard doesn't say anthing about threads.

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,
which just goes to show how utterly nonsensical their position is.

[CBFalconer]

dj******@csclub .uwaterloo.ca.i nvalid wrote:

>

.... snip ...

>
I have a bunch of malloc'ing code that I suspect has a memory-
management bug in it somewhere. Wouldn't it be nice if I could
just insert a #include at the top that pulls in some debugging
wrappers without having to change anything else in the code?

Try using DJGPP (see delorie.com) and installing nmalloc for it,
which has a comprehensive debugging package. See:

<http://cbfalconer.home .att.net/download/nmalloc.zip>

or you can try adapting the package to your system. The
non-standardisms are pretty common, but not all systems have a sbrk
call available.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Keith Thompson]

Antoninus Twink <no****@nospam. invalidwrites:

On 16 Oct 2008 at 21:20, ja*********@ver izon.net wrote:

>The only useful C answer to the thread-safe issue was to re-direct you
to forums more appropriate forum for such discussions, since the C
standard doesn't say anthing about threads.

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,

Yes.

which just goes to show how utterly nonsensical their position is.

No.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Dollin]

Antoninus Twink wrote:

On 16 Oct 2008 at 21:20, ja*********@ver izon.net wrote:

>The only useful C answer to the thread-safe issue was to re-direct you
to forums more appropriate forum for such discussions, since the C
standard doesn't say anthing about threads.

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,

Of course.

which just goes to show how utterly nonsensical their position is.

"nonsensica l" isn't the right spelling for "sensible", although I can
see how one could confuse them.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Richard Heathfield]

Chris Dollin said:

Antoninus Twink wrote:

>On 16 Oct 2008 at 21:20, ja*********@ver izon.net wrote:

>>The only useful C answer to the thread-safe issue was to re-direct you
to forums more appropriate forum for such discussions, since the C
standard doesn't say anthing about threads.

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,

Of course.

Right.

>which just goes to show how utterly nonsensical their position is.

"nonsensica l" isn't the right spelling for "sensible", although I can
see how one could confuse them.

"When the facts change, I change my mind. What do you do, sir?" - John
Maynard Keynes.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Chris Dollin wrote:

Antoninus Twink wrote:

>ja*********@ver izon.net wrote:

>>The only useful C answer to the thread-safe issue was to re-direct
you to forums more appropriate forum for such discussions, since
the C standard doesn't say anthing about threads.

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"'
own criteria questions about threads would suddenly become "on
topic" here,

Of course.

>which just goes to show how utterly nonsensical their position is.

"nonsensica l" isn't the right spelling for "sensible", although I
can see how one could confuse them.

Which word does not apply to any such C language inclusion. There
is still no mention of threads in the proposed draft of the next
system, and even if it was present it should be shouted down. C
operates in a simple environment, especially in embedded systems,
and nothing that bars that should be proposed. Note that C++ is
very definitely not C.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Flash Gordon]

CBFalconer wrote, On 17/10/08 15:16:

Chris Dollin wrote:

>Antoninus Twink wrote:

>>ja*********@ver izon.net wrote:

The only useful C answer to the thread-safe issue was to re-direct
you to forums more appropriate forum for such discussions, since
the C standard doesn't say anthing about threads.
The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"'
own criteria questions about threads would suddenly become "on
topic" here,

Of course.

>>which just goes to show how utterly nonsensical their position is.

"nonsensical " isn't the right spelling for "sensible", although I
can see how one could confuse them.

Which word does not apply to any such C language inclusion. There
is still no mention of threads in the proposed draft of the next
system, and even if it was present it should be shouted down. C
operates in a simple environment, especially in embedded systems,
and nothing that bars that should be proposed. Note that C++ is
very definitely not C.

I believe that there is talk of adding some threading support to the
next C standard and I don't see this as a problem for embedded systems.
The solution is simple and already in use, just as with the bulk of the
standard C library you make it only required for hosted implementations .
--
Flash Gordon
If spamming me sent it to sm**@spam.cause way.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/