|
|
 |
|
|
Thread Tools | Display Modes |
Apr 21st, 2006, 4:58 AM
|
#1 |
|
Programmer
Join Date: Dec 2005
Posts: 57
Rep Power: 0
 |
How can I get around Seg Faults
What are some handy ways to work aroudn them? I know the computer is just trying to do what best, but at times it really isnt necesary =P. What are some tricks u guys use to avoid these nasty errors?
Btw, i dont mean in a hacking way, i mean in more of a how do you avoid em way Last edited by metsfan; Apr 21st, 2006 at 5:15 AM. |
|
|
|
Apr 21st, 2006, 5:17 AM
|
#2 |
|
Programming Guru
 
Join Date: Jun 2005
Location: elemental plane
Posts: 1,429
Rep Power: 5
|
You don't understand what seg faults are. You don't even _want_ to get around seg faults. Seg faults are caused by bad programming. Messing with memory you don't possess isn't what you want to do. Taking another operating system which does not protect you against such things will do the trick though. It might blow up in your face, but that'd be your fault.
__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." -- Socrates |
|
|
|
|
Apr 21st, 2006, 5:20 AM
|
#3 |
|
Programmer
Join Date: Dec 2005
Posts: 57
Rep Power: 0
|
I dont think its fair to say that causing a Seg fault makes you a "bad" programmer, maybe just one that doenst have much experience with C. Things that cause Seg faults in C would not even compile in some other languages, and would execute just fine in others
I also like to have the freedom to do what I want, I know the programmers who made the OS put it there for a reason, but its my computer, and my memory. Besides, im not looking for a way to make the computer NOT seg fault when it should, i waas just wondering if you guys had any ways around em that are still legal |
|
|
|
|
Apr 21st, 2006, 5:33 AM
|
#4 | ||||
|
Programming Guru
Join Date: Jun 2005
Location: elemental plane
Posts: 1,429
Rep Power: 5
|
Quote:
Quote:
Quote:
Quote:
 Segfaults are always generated when it should. If you want to do something in other processes, that's fine and can be done by asking the OS.What you are saying is like saying you don't want to go to jail when you steal. The cops should still put you in jail when you do steal, but you would like a way around it so you can still steal and not go to prison. It doesn't make any sense.
__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." -- Socrates |
||||
|
|
|
|
Apr 21st, 2006, 5:47 AM
|
#5 |
|
Programmer
Join Date: Dec 2005
Posts: 57
Rep Power: 0
|
well, the reason this is getting me so heated is for the following reason: In the program I am currently writing, i have #defined two macros, which are essentially identical, and some helper macros. The program I am writing is a memory allocator. the macros look as following:
/* Pack a size and allocated bit into a word */ #define PACK(size, alloc) ((size) | (alloc)) /* Read and write a word at address p */ #define GET(p) (*(unsigned int *)(p)) #define PUT(p, val) (*(unsigned int *)(p) = (val)) /* Read the size and allocated fields from address p */ #define GET_SIZE(p) (GET(p) & ~0x7) #define GET_ALLOC(p) (GET(p) & 0x1) /* Given block ptr bp, compute address of its header and footer */ #define HDRP(bp) ((char *)(bp) - WSIZE) #define FTRP(bp) ((char *)(bp) + GET_SIZE(HDRP(bp)) - DSIZE) and I use them in the following way: PUT(HDRP(ptr),PACK(size, 0)); PUT(FTRP(ptr),PACK(size, 0)); I am using these to define the header and footer pointers of the blocks of an explicit free list malloc implementation. However, what is really irking me is that HDRP always seems to work, while FTRP constantly seg fault.s I really only see that there are two possible reasons for this seg fault: 1. The pointer being pased doenst like being dereferenced by GET(p) 2. The additional invasive references to the pointer parameter in FTRP are causing problems, since the pointer is abused more by it than bay HDRP. Reason number one was what I really thought it was, so I changed the macro to the following, in an effort to avoid this call to Get(p): #define FTRP(bp,size) (((char *)(bp) + size) - DSIZE)) I simply took the size value that Header pointer uses to define its own size, and sent it in as a parameter, thus completely avoiding the dereferencing done by Get(p) but it still produced a Seg faults every time, while HDRP runs smoothly. I also tried switching the order of them so that FTRP comes first, and it makes no difference. In addition, with this new form, it does not do any mroe references to the pointer than HDRP does. I thought it was an isolated incident, so i tested it with multiple references to the macros and with multiple different pointers. All the same result As you can imagine, this was getting quite frustrating. I agree that Seg faults have their reaosns, but there are just those times you wish there was an easy way to get around em and get on wiht your life. So please, if anyone knows any LEGAL ways to get around a Seg fault, please help me out. |
|
|
|
|
Apr 21st, 2006, 5:52 AM
|
#6 |
|
Programming Guru
Join Date: Jun 2005
Location: Adelaide, South Australia
Posts: 1,260
Rep Power: 5
|
The accepted way to avoid segmentation faults is to ensure that an invalid pointer is never dereferenced.
Some common ways of doing this in C are; 1) Never dereference a NULL or uninitialised pointer. Avoiding dereferencing a NULL is easy: simply check if it is not NULL before dereferencing it. Avoiding dereferencing an uninitilialised pointer is harder, as it is not possible to check if a pointer is uninitialised (it may point at anything), so usually relies on designing a program so you know an uninitialised pointer is not dereferenced. For example; int *x;
*x = 42; int a;
int *x;
x = &a;
*x = 42; int *x;
x = malloc(sizeof int);
*x = 42;2) If working with arrays, never attempt to access an array element that does not exist. This comes in two forms: if working with an index, ensure the index is between 0 and length-1, where length is the number of elements in the array. If working with a pointer, ensure the pointer points within the array. For example; int x[20];
int i;
int length = 20;
for (i = 0; i < length; ++i) /* valid accessing of array */
x[i] = 42;
for (i = 0; i <= length; ++i) /* invalid accessing of array */
x[i] = 24; int x[20];
int *px, *one_past_end = px + 20;
for (px = x; px < one_past_end; ++px) /* valid accessing of array */
*px = 42;
for (px = x; px <= one_past_end; ++px) /* invalid accessing of array */
*px = 24;3) Never free() a pointer that is not the result of a malloc() or realloc(). int a;
int *x = &a;
free(x); /* Potential boom */4) Never free() a pointer more than once. int *x = malloc(sizeof int);
free(x);
free(x); /* Potential boom */5) Never derefence a pointer after free()ing it; int *x = malloc(sizeof int);
free(x);
*x = 42; /* potential boom */6) If a function returns a pointer, never return a non-static local; int *Func()
{
int x;
return &x; /* The error is here */
}
int main()
{
int *x = Func();
*x = 42; /* Potential boom */
}7) If a function accepts a pointer, and uses it to return data to the caller, ensure the caller passes the address of a valid object; void Func(int *x)
{
*x = 42; /* boom can occur here */
}
int main()
{
int *x;
Func(x); /* error is here (passing uninitialised pointer) */
}8) If a function accepts a pointer and assumes it is not NULL, don't pass a NULL. #include <string.h>
int main()
{
char x[10];
strcpy(x, (char *)NULL);
}9) If a pointer accepts a NULL terminated string, ensure it receives one. #include <string.h>
int main()
{
char x[10], y[10];
strcpy(x, y); /* Potential boom (y is uninitialised, so not guaranteed to be zero terminated) */
}10) If a function assumes a relationship between it's arguments, honour them; #include <string.h>
int main()
{
char x[5];
strcpy(x, "ABCDE"); /* Potential boom as x is not long enough to hold "ABCDE" */
}There are lots of variations..... |
|
|
|
|
Apr 21st, 2006, 5:56 AM
|
#7 |
|
Programmer
Join Date: Dec 2005
Posts: 57
Rep Power: 0
|
wow thanx a lot grumpy, really helpful
|
|
|
|
|
Apr 21st, 2006, 5:59 AM
|
#8 | |
|
Programming Guru
Join Date: Jun 2005
Location: Adelaide, South Australia
Posts: 1,260
Rep Power: 5
|
Quote:
It is not possible to make segmentation faults just go away, as they result from invalid memory accesses. The trick is to avoid them in the first place. |
|
|
|
|
|
Apr 21st, 2006, 6:18 AM
|
#9 | |
|
Programming Guru
Join Date: Jun 2005
Location: elemental plane
Posts: 1,429
Rep Power: 5
|
Great suggestions grumpy, it should be in the FAQ (if we had one).
Quote:
__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." -- Socrates |
|
|
|
|
|
Apr 21st, 2006, 6:25 AM
|
#10 |
|
Expert Programmer
Join Date: Jun 2005
Posts: 893
Rep Power: 4
|
Another thing that may be happening, depending on your hardware, is that accessing an int at an odd memory location (as opposed to an even one) may not be allowed. For example Sun Sparc is like this. If this is the problem and you still need to read ints at a certain location, you would need to access them as two chars and calculate the value yourself (by shifting left and adding). This would probably make your code less portable though.
|
|
|
|
|
| Bookmarks |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | |
|
|
Linear Mode
