Detecting dangling memory references

[Richard]

My experience has always been that you're SOL when trying to safely
detect and stop references to dangling memory (non-null pointers to
free'ed blocks) at runtime (C99, Linux).

Maybe somebody clever has worked this out, though?

(Apologies to those who find the question off topic for CUP or CLC)

 

[Richard]

(e-mail address removed) wrote...

My experience has always been that you're SOL when trying to safely
detect and stop references to dangling memory (non-null pointers to
free'ed blocks) at runtime (C99, Linux).

Maybe somebody clever has worked this out, though?

(Apologies to those who find the question off topic for CUP or CLC)

Before somebody says "fix your code," the pointer is coming to me
from a library. Valgrind is claiming it's a non-null pointer to a
block that hasn't been allocated.

 

[Karthik]

My experience has always been that you're SOL when trying to safely
detect and stop references to dangling memory (non-null pointers to
free'ed blocks) at runtime (C99, Linux).

Maybe somebody clever has worked this out, though?

(Apologies to those who find the question off topic for CUP or CLC)

There is electric fence that can help with this too !!

 

[joe]

(e-mail address removed) wrote...

You'll probably get complaints from clc, but it's certainly on topic
in cup.

Before somebody says "fix your code," the pointer is coming to me
from a library. Valgrind is claiming it's a non-null pointer to a
block that hasn't been allocated.

Then you might want to send that output to the maintainers of the
library and suggest they look into it. What else can you do if you
don't control the code?

Depending on your platform there are probably other memory checkers
you could use. What OS are you doing this on?

Joe

 

[CBFalconer]

(e-mail address removed) wrote...

Valid for cup I expect, and should be of interest here on clc.

Before somebody says "fix your code," the pointer is coming to
me from a library. Valgrind is claiming it's a non-null pointer
to a block that hasn't been allocated.

You may want to look at my nmalloc for DJGPP. It is close to
standard C, but depends on various things (including pointer
arithmetic and sbrk) and the variadic macros are built around the
gcc (non-standard) technique. Those macros are only needed for
debuggery, but the variadic nature makes it impossible to just
define them out, thus you need gcc.

The point of this is that nmalloc has internal checks for
validity. Some of them are turned off by "#define SAVEMEMORY =
1". I originally had this enabled, which installed guard values
above and below the actual memory assignments, and with it
restored it should be possible to create an "int
_nmalloc_validptr(void *);" to provide close assurance of
validity, by checking that the block is assigned, with valid
forward and backwards pointers, and that the guards have not been
mangled.

If your existing code can be compiled under DJGPP you could try
most of this out with no changes. See the malldbg module in
nmalloc.

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

 

[Peter Nilsson]

C99? Are you sure?

You'll probably get complaints from clc, but it's certainly on topic
in cup.

It's on topic in clc and the answer is 'yes, you're sol'. Answers from
cup involving implementation specific codings or third party libraries
will be off topic to clc though, so setting followups would be
appreciated.