| | |
segmentation fault
![]() |
•
•
Join Date: Jan 2005
Posts: 33
Reputation:
Solved Threads: 0
Can anyone please explain to me the following strange phenomenon?
I have a code in C, and when I compile it is Windows Platform compiler (Borland 5.5), they compiling is fine and when I execute the program, everything turns out ok.
However, when I use the same code and compile it in UNIX, the compiling is ok but when I execute the program I get a "Segmentation fault" message?
I have a code in C, and when I compile it is Windows Platform compiler (Borland 5.5), they compiling is fine and when I execute the program, everything turns out ok.
However, when I use the same code and compile it in UNIX, the compiling is ok but when I execute the program I get a "Segmentation fault" message?
There is a bug in the code. You are fortunate that the UNIX platform at least shows you this; in Windows it is just "lucky" to be running.
"One of the methods used by statists to destroy capitalism consists in establishing controls that tie a given industry hand and foot, making it unable to solve its problems, then declaring that freedom has failed and stronger controls are necessary." --Ayn Rand
>if there is a bug in the code, why doesn't it show when I compile?
*stunned silence*
>how can i rectify the problem?
Take my suggestions and look for off by one errors when you index an array or places you might have an uninitialized pointer.
>I thought segmentation fault has got to do with memory errors...
Yes. If you access memory outside of your address space, you get a segmentation fault.
>or is this a portability issue?
No, it's a programmer issue. Fix your broken code.
*stunned silence*
>how can i rectify the problem?
Take my suggestions and look for off by one errors when you index an array or places you might have an uninitialized pointer.
>I thought segmentation fault has got to do with memory errors...
Yes. If you access memory outside of your address space, you get a segmentation fault.
>or is this a portability issue?
No, it's a programmer issue. Fix your broken code.
I'm here to prove you wrong.
Yes, segmentation fault has chased me long enough when i was learning pointers. Most of the time it gotta do something with the pointers or array. It occurs when...
1. U de-reference a NULL pointer.
2. U de-reference an uninitialized pointer --which results in accessing memory outside of ur memory space.
3. Indexing an array where the index is out of the arrays boundary---- which also means accessing not permitted memory space.
That are the three reasons i can rem for now.
As far as i know the program should have crashed in Windows pc if it were the first case. Since it works with windows itz perhaps either the second or the third case. Look for array bounds, especially in Loops.
1. U de-reference a NULL pointer.
2. U de-reference an uninitialized pointer --which results in accessing memory outside of ur memory space.
3. Indexing an array where the index is out of the arrays boundary---- which also means accessing not permitted memory space.
That are the three reasons i can rem for now.
As far as i know the program should have crashed in Windows pc if it were the first case. Since it works with windows itz perhaps either the second or the third case. Look for array bounds, especially in Loops.
It depends on what you mean by "run out of memory". If malloc fails then it returns a null pointer, which would cause a seg fault if you don't test for failure. However, malloc failure is extremely unlikely these days, so the problem is still probably something you did wrong. If running out of "stack" space for automatic variables caused a segmentation fault, I would still be suspicious of your code because Unix is very good about growing the "stack" if needed. So if you're actually running out of memory (meaning fast memory and virtual memory), there's a lot more wrong with your code than a little error.
Unfortunately, memory errors are very difficult to find, and without actual code to look at, we're just making educated guesses.
Unfortunately, memory errors are very difficult to find, and without actual code to look at, we're just making educated guesses.
I'm here to prove you wrong.
![]() |
Similar Threads
- Access Violation (Segmentation Fault) + atol (C++)
- unix/C++ segmentation fault (C++)
- what is the best way to track segmentation fault errors (C++)
Other Threads in the C Forum
- Previous Thread: summation
- Next Thread: Using binary operators!
| Thread Tools | Search this Thread |
* adobe api array asterisks binarysearch calculate changingto char character cm copyanyfile copyimagefile copypdffile creafecopyofanytypeoffileinc createcopyoffile createprocess() csyntax database directory feet fgets file floatingpointvalidation forloop frequency function givemetehcodez global grade gtkgcurlcompiling gtkwinlinux hacking highest histogram homework i/o infiniteloop input interest intmain() iso kernel keyboard kilometer km linked linkedlist linux looping loopinsideloop. lowest meter microsoft mqqueue mysql number oddnumber odf open openwebfoundation owf pdf performance posix power probleminc process programming pyramidusingturboccodes radix read recv recvblocked repetition research reversing scheduling segmentationfault send sequential single socket socketprogramming stack standard string suggestions systemcall threads turboc unix urboc user variable wab whythiscodecausesegmentationfault win32api windows.h windowsapi






