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]

Re: Detecting dangling memory references

rh310@hotmail.c om wrote...[color=blue]
> 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)[/color]

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]

Re: Detecting dangling memory references

Richard wrote:[color=blue]
> 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)[/color]

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


--
Karthik.
Humans please 'removeme_' for my real email.

[joe@invalid.address]

Re: Detecting dangling memory references

Richard <rh310@hotmail. com> writes:
[color=blue]
> rh310@hotmail.c om wrote...[color=green]
> > 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)[/color][/color]

You'll probably get complaints from clc, but it's certainly on topic
in cup.
[color=blue]
> 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.[/color]

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
--
"Surprise me"
- Yogi Berra when asked where he wanted to be buried.

[CBFalconer]

Re: Detecting dangling memory references

Richard wrote:[color=blue]
> rh310@hotmail.c om wrote...
>[color=green]
>> 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)[/color][/color]

Valid for cup I expect, and should be of interest here on clc.
[color=blue]
>
> 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.[/color]

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_validp tr(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>

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.

[Peter Nilsson]

Re: Detecting dangling memory references

joe@invalid.add ress wrote in message news:<m3y8o9i8t p.fsf@invalid.a ddress>...[color=blue]
> Richard <rh310@hotmail. com> writes:[color=green]
> > rh310@hotmail.c om wrote...[color=darkred]
> > > 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).[/color][/color][/color]

C99? Are you sure?
[color=blue][color=green][color=darkred]
> > > Maybe somebody clever has worked this out, though?
> > >
> > > (Apologies to those who find the question off topic for CUP or
> > > CLC)[/color][/color]
>
> You'll probably get complaints from clc, but it's certainly on topic
> in cup.[/color]

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.

--
Peter