IsBadWritePtr equivalent?

[rohit]

I am porting a C code from Windows base to Linux/Macintosh OS and need
an implementation of "IsBadWritePtr" for gcc to run the app on
Mac/Linux.

Below is the detailed info:
IsBadWritePtr in Windows, basically verifies that the calling process
has write access to the specified range of memory.

But unfortunately I am not finding any way to verify the memory on Mac
(using gcc 4.0)

I have a structure called DevCon, and I check if the validity of the
same in windows using the following macro:

#define IsValid(DevCon) IsBadWritePtr(DevCon,4)

So if the calling process has write access to all bytes in the
specified memory range, then it returns 0 else 1. This way I easily get
to know the validity.

In Linux/Mac, I tried to simulate the same using below code, but it
gave me the segmentation fault.

int IsValid(DEV_CON DevCon){

if(DevCon->MyFirstElement == "FIXEDVALUE") ===> I get the segmentation
fault.
{
}

}

Please Note: The app is designed in such a way that the pointer
pointing to the structure always have some value. (it is never null) On
the other hand the structure it is pointing to is only freed. So this
is the reason we used IsBadWritePtr in Windows.

1) Do we have try catch throws in gcc ? So that it can be possible to
suppress the crash ?
2) Is there readily available API of IsBadWritePtr in gcc ? If not, can
anybody show the implementaion for the same?

Please let me know for any clarification in this regards,
Rohit

 

[Richard Heathfield]

rohit said:

1) Do we have try catch throws in gcc ?

We don't have them in C.

So that it can be possible to suppress the crash ?

Instead of suppressing it, why not find and fix the cause?

2) Is there readily available API of IsBadWritePtr in gcc ?

There is none in the C language.

If not, can
anybody show the implementaion for the same?

The implementation in C is kind of distributed. Here it is:

1) When you define the pointer, ensure that it's either valid (by pointing
it at a valid object or function) or NULL.

2) Whenever you change the pointer value, ensure that the new value is
either valid or NULL.

3) Check that a pointer value is not NULL before relying on that value.

 

[robertwessel2]

I am porting a C code from Windows base to Linux/Macintosh OS and need
an implementation of "IsBadWritePtr" for gcc to run the app on
Mac/Linux.

Below is the detailed info:
IsBadWritePtr in Windows, basically verifies that the calling process
has write access to the specified range of memory.

But unfortunately I am not finding any way to verify the memory on Mac
(using gcc 4.0)

I have a structure called DevCon, and I check if the validity of the
same in windows using the following macro:

#define IsValid(DevCon) IsBadWritePtr(DevCon,4)

So if the calling process has write access to all bytes in the
specified memory range, then it returns 0 else 1. This way I easily get
to know the validity.

In Linux/Mac, I tried to simulate the same using below code, but it
gave me the segmentation fault.

int IsValid(DEV_CON DevCon){

if(DevCon->MyFirstElement == "FIXEDVALUE") ===> I get the segmentation
fault.
{
}

}

Please Note: The app is designed in such a way that the pointer
pointing to the structure always have some value. (it is never null) On
the other hand the structure it is pointing to is only freed. So this
is the reason we used IsBadWritePtr in Windows.

1) Do we have try catch throws in gcc ? So that it can be possible to
suppress the crash ?
2) Is there readily available API of IsBadWritePtr in gcc ? If not, can
anybody show the implementaion for the same?

Please let me know for any clarification in this regards,

While entirely OT...

To expand on what Richard said... You can't do this in standard C, and
even in Windows, IsBadXxxPtr() is probably *not* actually doing what
you want.

The IsBadXxxPtr() functions check to see if the memory being pointed to
can be accessed. This is based on the OS's mapping/allocation of pages
into the address space. This has little to do with C's notion of
allocated and freed memory. Almost never will free() actually return
the page to the OS, and the pointer, even though pointing to an area
free()'d, will still be pointing to addressable storage, and IsBad will
return OK. Even worse, the very next malloc(), of any type of object,
can trivially reuse the area freed.

It's extremely rare the IsBadXxxPtr() is actually useful. If you need
it, you more likely have a bug in your program, because it DOES NOT
tell you if a pointer is actually good. In fact, in most cases
isBadXxxPtr() will forever return true once the malloc() has been done,
since most of the time the CRT will never return heap pages to the OS.

Let me repeat that. IsBadXxxPtr() does not, can not, will not, with
even a small degree of reliability, determine if a pointer is pointing
to a freed area. It does not do that, it will not work.

 

[Richard Tobin]

The implementation in C is kind of distributed. Here it is:

1) When you define the pointer, ensure that it's either valid (by pointing
it at a valid object or function) or NULL.

2) Whenever you change the pointer value, ensure that the new value is
either valid or NULL.

3) Check that a pointer value is not NULL before relying on that value.

You missed

4) Do not use a pointer after the lifetime of the memory it points to.

-- Richard

 

[Richard Heathfield]

Richard Tobin said:

You missed

4) Do not use a pointer after the lifetime of the memory it points to.

You're right that you should not use such a pointer, but I don't agree that
I missed it. When the object pointed to ceases to exist, the value of the
pointer changes. (Not the object representation; the *value*.) And so my
point (2) covers it - "ensure that the new value is either valid or NULL".
We know it's not valid (because the object it pointed to just died), so we
should set it to NULL.

 

[Lew Pitcher]

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

rohit said:



We don't have them in C.

But, we /do/ have signals and signal handlers

Although the circumstances may vary, environment to environment, the
standard SIGSEGV signal should be issued on "an invalid access to
storage". This is one of the signals defined in the standard, and a
signal handler function should be able to intercept it.

Yes, for a limited solution. But, you want to do more than "suppress
the crash"; you want to repair the cause of the crash, and prevent any
further crashes. You could do some of this with signal handler code,
but the general case would be pretty convoluted. Better to follow RH's
advice and just "find and fix the cause" before it causes a crash.

Instead of suppressing it, why not find and fix the cause?

Agreed.

[snip]

HTH
- --
Lew Pitcher

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFFLOeyagVFX4UWr64RAo22AKDzRnZKYP6sQjZvkqbHjburlk28DACfegFI
4EuPVr7LmRHpMnkMi2SvmoE=
=O43a
-----END PGP SIGNATURE-----

 

[rohit]

How about following code:
#include <setjmp.h>
#include <signal.h>

static jmp_buf hndbuf;

static void handler(int ignored)
{
(void)ignored;
longjmp(hndbuf, 1);
}

static BOOL IsBadWritePtr(const void *lp, size_t ucb)
{
struct sigaction act;
struct sigaction oact;
char *base = (void*)lp;
char *over = base + ucb;
volatile char *test;

act.sa_handler = handler;
sigemptyset(&act.sa_mask);
act.sa_flags |= SA_RESTART;

if (sigaction(SIGSEGV, &act, &oact) < 0) {
return FALSE; /* Debatable action */
}

switch (setjmp(hndbuf)) {
case 0:
for (test = base; test < over; test++) {
*test = *test;
}

(void)sigaction(SIGSEGV, &oact, NULL);
return FALSE;
default:
break;
}

(void)sigaction(SIGSEGV, &oact, NULL);
return TRUE;
}
Rohit

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

rohit said:



We don't have them in C.

But, we /do/ have signals and signal handlers

Although the circumstances may vary, environment to environment, the
standard SIGSEGV signal should be issued on "an invalid access to
storage". This is one of the signals defined in the standard, and a
signal handler function should be able to intercept it.

Yes, for a limited solution. But, you want to do more than "suppress
the crash"; you want to repair the cause of the crash, and prevent any
further crashes. You could do some of this with signal handler code,
but the general case would be pretty convoluted. Better to follow RH's
advice and just "find and fix the cause" before it causes a crash.

Instead of suppressing it, why not find and fix the cause?

Agreed.

[snip]

HTH
- --
Lew Pitcher

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFFLOeyagVFX4UWr64RAo22AKDzRnZKYP6sQjZvkqbHjburlk28DACfegFI
4EuPVr7LmRHpMnkMi2SvmoE=
=O43a
-----END PGP SIGNATURE-----

 

[Chris Dollin]

How about following code:
#include <setjmp.h>
#include <signal.h>

static jmp_buf hndbuf;

static void handler(int ignored)
{
(void)ignored;
longjmp(hndbuf, 1);
}

If this signal handler is invoked other than via `abort` or
`raise`, the effect is undefined, because it calls a library
function other than `signal`. (At least according to this
here C89 draft.)

I think you need a stronger standard than C. (OT does Posix
allow this reliably?)

 

[CBFalconer]

How about following code:
#include <setjmp.h>
#include <signal.h>

....
top-posted article ignored. See following links.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Kenny McCormack]

...
top-posted article ignored. See following links.

But it wasn't ignored. You clearly read it, interpreted it, and, most
significantly of all, responded to it.

Some informative links:
<<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

Those are good, but these are better - should be required first reading
for new posters here:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

 

[Bart]

While entirely OT...
Indeed.

Let me repeat that. IsBadXxxPtr() does not, can not, will not, with
even a small degree of reliability, determine if a pointer is pointing
to a freed area.

"cannot" is too strong. It is not meant to be used in conjunction with
malloc/free, but can work in programs that allocate using the Win32
directly. But I agree that it's superfluous in reliable programs.

Regards,
Bart.

 

[robertwessel2]

"cannot" is too strong. It is not meant to be used in conjunction with
malloc/free, but can work in programs that allocate using the Win32
directly. But I agree that it's superfluous in reliable programs.

Only if you're looking at storage directly allocated with
VirtualAlloc() and friends. Using the Win32 HeapXxxx() functions has
the same problem as using the CRT's heap (assuming the CRT isn't just
using a Win32 heap). With any sort of conventional heap structure,
IsBadXxxPtr() simply can't do what we're assuming the OP wants it to
do. As I pointed out, in most cases it will never return false for a
pointer to a block that's been allocated, even if it has been freed
(since the heap will not usually release the underlying pages).

Implementing such a function requires some access to the heap
implementation, but that's fairly commonly available (if entirely
implementation specific). For example, in MSVC you could use the
_heapwalk() function to validate the pointer (not very quickly, but the
implementation is trivial). The CRTs used with GCC usually have a
similar HeapWalk() function. Even then this does nothing to detect
reuse of that memory area in a new allocation.

 

[Spiro Trikaliotis]

Hello,

(e-mail address removed) wrote:

"cannot" is too strong. It is not meant to be used in conjunction with
malloc/free, but can work in programs that allocate using the Win32
directly. But I agree that it's superfluous in reliable programs.

Although it is totally OT here, let's see what a Microsoft employee,
Raymond Chen, has to tell about it:

"IsBadXxxPtr should really be called CrashProgramRandomly"
http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx

Regards,
Spiro.

 

[Tom St Denis]

Those are good, but these are better - should be required first reading
for new posters here:

How about the CLC FAQ?

You seem to be upset that the regulars aren't doing all in their power
to help off topic discussions flourish.

Newsflash. Life isn't always going to turn out how you want. This is
comp.lang.c and nothing else. If you want to get upset, get upset at
the script monkeys, slackers [students] and others who make up the
majority [*] of off topic posts.

Tom

[*] there are the occasional innoncent posters who just don't know
better but most questions here seem to be either homework or
professionally related. So they deserve neither patience or anything
more than the most concise reply.

 

[Keith Thompson]

Kenny McCormack wrote: [snip]

How about the CLC FAQ?

You seem to be upset that the regulars aren't doing all in their power
to help off topic discussions flourish.

Tom, Kenny McCormack is simply a troll, nothing more, nothing less.
Please ignore him.