Local Heap?

[William L. Bahn]

I am having a strange problem - and I suspect it is something
specific to my compiler - but want to get a read on the Standard
C portion of it first.

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

I have a program that does a lot of things. I don't have the code
handy to post, but I think a word description will do. I'd be
more than happy to post code if someone thinks it would be
helpful.

One function "dynamically copies a string" - so I pass a pointer
to a string, it checks the length of the string, allocates
sufficient memory, copies the string into the new memory, and
returns the value of the new pointer.

I have another function that does a few things, one of which is
to call the dynamic string copy function. It then does some other
things and returns the pointer to the new string to main(). That
works just fine (yes, including the null terminator). In main(),
I perform some manipulations on that string and then free the
pointer. That works fine.

I then made a copy of the function - literally - and changed the
name slightly and changed some of the miscellaneous details that
it does - but the dynamic copy works the same. When I run it, I
get a run time error when I call free() in main() and looking
through the debug headers it appears that this new version is
trying to free up memory that is not in the "Local Heap Space".
I've never heard of that? What gives?

I checked the value of the pointer within the function and the
value that gets returned and the value in the pointer at the time
that free() is called and they all agree. I copied the code from
the original function into the new function so that the only
remaining difference is the function names. The old function
works, the new function throws the error. The only way I can get
my program to run is to not perform the garbage collection?

Any thoughts?

 

[Karthik Kumar]

I am having a strange problem - and I suspect it is something
specific to my compiler - but want to get a read on the Standard
C portion of it first.

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

I have a program that does a lot of things. I don't have the code
handy to post, but I think a word description will do. I'd be
more than happy to post code if someone thinks it would be
helpful.

Anyday, few lines of C code would be better compared to plain
English !!

One function "dynamically copies a string" - so I pass a pointer
to a string, it checks the length of the string, allocates
sufficient memory, copies the string into the new memory, and
returns the value of the new pointer.

I have another function that does a few things, one of which is
to call the dynamic string copy function. It then does some other
things and returns the pointer to the new string to main(). That
works just fine (yes, including the null terminator). In main(),
I perform some manipulations on that string and then free the
pointer. That works fine.

I then made a copy of the function - literally - and changed the
name slightly and changed some of the miscellaneous details that
it does - but the dynamic copy works the same. When I run it, I
get a run time error when I call free() in main() and looking
through the debug headers it appears that this new version is
trying to free up memory that is not in the "Local Heap Space".
I've never heard of that? What gives?

What are those 'miscellaneous details' ?

What is the name of the function that you had chosen ? Are you sure
that there is no pollution of the function names here ?

I checked the value of the pointer within the function and the
value that gets returned and the value in the pointer at the time
that free() is called and they all agree. I copied the code from
the original function into the new function so that the only
remaining difference is the function names. The old function
works, the new function throws the error. The only way I can get
my program to run is to not perform the garbage collection?

Any thoughts?

Please post the source code ( a small, compilable one that describes
the problem precisely) for people to help.

 

[kevin.bagust]

I am having a strange problem - and I suspect it is something
specific to my compiler - but want to get a read on the Standard
C portion of it first.

Strange problem, it sounds like undefined behavoiur somewhere in your
program, rather than a compiler problem.

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

Two possiblities:
1) You have already freed that section of memory.
2) You have invoked undefined behaviour somewhere in your program.

I then made a copy of the function - literally - and changed the
name slightly and changed some of the miscellaneous details that
it does - but the dynamic copy works the same. When I run it, I
get a run time error when I call free() in main() and looking
through the debug headers it appears that this new version is
trying to free up memory that is not in the "Local Heap Space".
I've never heard of that? What gives?

It sounds like somewhere in your program you are writing outside of a
valid object. Which is doing strange things to malloc memory area. This
could be writing before the start or after the end of a malloced area of
memory, writing through a uninitialized pointer.

Any thoughts?

You could try Linting the code, or using a malloc debugging library if
there is one avalible for your platform.

These are only guesses, to get more help you need to post a version of
code that has had as much code as possible removed from it but still shows
the problem.

Kevin.

 

[pete]

I am having a strange problem - and I suspect it is something
specific to my compiler - but want to get a read on the Standard
C portion of it first.

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

If that value has already been used in a free() call,
since the time when it was returned by malloc.

 

[CBFalconer]

I am having a strange problem - and I suspect it is something
specific to my compiler - but want to get a read on the Standard
C portion of it first.

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

If it already has been freed.

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If it already has been freed.

Couldn't you add
"or, if it already has been passed to the realloc() function"
to this statement?

- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFBNxCiagVFX4UWr64RAhgcAKCZphoUPjYE84VzTTiflqX5ZfiFEQCg0e6g
Fhbq90fm0AgHNiWSRtPTS6o=
=1Bg4
-----END PGP SIGNATURE-----

 

[Michael Kurz]

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

Normally this should not happen, but:
1.
-I once worked on a C Compiler for a Microcontroller, which had broken
a
Clib, as if it really ran out of memory (no physical memory left)
malloc() did not return 0, although the memory was not allocated, but
this is very rare.

2.
You accidently freed the memory with free previously. (but as you
already said
you dont, well)

3.
Memory corruption
Where is the address stored? Global data?, stack?
If its stored on a stack variable it could possibly be a corrupted
stack
(Write an array variable over its real size, ...)

A similar thing could happen if its a global.

So what I would do is:
Look if the address value is the same when it is allocated and when it
is freed.
If not well, then you know its probably a memory (global, stack)
corruption .

Regards
Michael

 

[CBFalconer]

Couldn't you add
"or, if it already has been passed to the realloc() function"
to this statement?

Not necessarily. It may be so. However some system packages (my
nmalloc especially) go to pains to avoid unnecessary copying and
thus to return the same pointer if possible. Anytime realloc
returns NULL it is possible to free the original pointer, assuming
nothing else has fouled it.

 

[Matthew Fisher]

I am having a strange problem - and I suspect it is something
specific to my compiler - but want to get a read on the Standard
C portion of it first.

Basic Question: Under the C Standard, under what conditions, if
any, can a value returned by malloc() not be used in a subsequent
free() call?

William,

You have a clear case for heap corruption. (Mis)use of malloc/free
can lead to the heap being corrupted. One the heap is corrupted
results from malloc and free are both undefined. In you particular
case, you may a freed a global or stack variable. A subsquent malloc
would then return that value as a pointer. The final call to free
then is totally confused.

There are several freeware tools to help with this problems. Check
out Valgrind and mpatrol. My company, Dynamic Memory Solutions,
markets the commercial tool, Dynamic Leak Check (DLC). The DLC
catches heap corrupting error and leak by replacing the normal
malloc/free routine as runtime. See www.dynamic-memory.com

Good luck,
Matthew
Dynamic Memory Solutions
www.dynamic-memory.com

 

[CBFalconer]

You have a clear case for heap corruption. (Mis)use of malloc/free
can lead to the heap being corrupted. One the heap is corrupted
results from malloc and free are both undefined. In you particular
case, you may a freed a global or stack variable. A subsquent malloc
would then return that value as a pointer. The final call to free
then is totally confused.

There are several freeware tools to help with this problems. Check
out Valgrind and mpatrol. My company, Dynamic Memory Solutions,
markets the commercial tool, Dynamic Leak Check (DLC). The DLC
catches heap corrupting error and leak by replacing the normal
malloc/free routine as runtime. See www.dynamic-memory.com

Good luck,
Matthew
Dynamic Memory Solutions
www.dynamic-memory.com

This continuous vending of an apparently obviously flawed
commercial system is getting on my nerves. There is a free
implementation of malloc/free/realloc, which also affords fairly
comprehensive debugging tools, designed for the DJGPP system and
which I believe will function quite adequately on any Linux system
that supplies sbrk(). It is NOT standard C, and uses GNU flavor
(not C99) variadic macros for debugging itself (thus they can be
removed with care).

There is no guarantee that any replacement for malloc etc. will
function in a C system, the very act of so doing is expressly
forbidden by the standard. It is probably especially obnoxious in
a C++ system, but that is OT here (F'ups set).

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