llagreca
asked on
Segmentation Faults
I read in a file, do manipulations or calculations and then read in another file and do the same manipulations or calculation. I do this for a lot of files. Sometime after the file has been read in, and it starts to do the manipulations and calculations I get a segmenation fault. What could cause this? It doesn't happen on may files. Could it be the was the file was set up (it is a binary file)? Or is it something in my code? Any suggestions would be appreciated?
Thanks
Thanks
ASKER
But why doesn't this happen when I do the manipulations to every file?
> But why doesn't this happen when I do the manipulations to every file?
That depends on your code; is there any special case handling depending on the data read from the file? Such parts of the code would not always execute.
If you are not familiar with debugging under Unix -- can be a quite complex task -- try this to track hanging pointers:
- always initialize pointers to NULL
- when you free() memory, set the pointer to NULL afterwards
- #include <assert.h>
- preceede every use of pointers with an assert statement like assert(my_pointer != NULL);
note: assert() is a macro, you can leave it inside your source files and simply #define NODEBUG when you're compiling for a release version.
That depends on your code; is there any special case handling depending on the data read from the file? Such parts of the code would not always execute.
If you are not familiar with debugging under Unix -- can be a quite complex task -- try this to track hanging pointers:
- always initialize pointers to NULL
- when you free() memory, set the pointer to NULL afterwards
- #include <assert.h>
- preceede every use of pointers with an assert statement like assert(my_pointer != NULL);
note: assert() is a macro, you can leave it inside your source files and simply #define NODEBUG when you're compiling for a release version.
what about your code send it to EE
we will try to help you
we will try to help you
If you give the stack trace of the core dump we should be able to
help you. Which version of OS are you using? Do you have
a debbugger installed on your machine? If you have one use it
to get the stack trace and let us know
help you. Which version of OS are you using? Do you have
a debbugger installed on your machine? If you have one use it
to get the stack trace and let us know
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
amorousdonjuan: I have never seen a 'Segmentation fault, core dumped' message on a DOS/Windows system -- these are the typical famous last words of an Unix program.
> a segmentation fault occurs when a program accesses an area of memory (overwriting the memory) to which it does not have access.
Right, it does not have access to that address, thus it cannot overwrite anything.
> the problem with pointers is that they exist even after you finish executing the program.so sometimes you might have to hardboot the system in order to free the memory.
Under Unix all resources used by a process are freed when it terminates; no need to reboot. Remember: Unix is an operating system :-)
> a segmentation fault occurs when a program accesses an area of memory (overwriting the memory) to which it does not have access.
Right, it does not have access to that address, thus it cannot overwrite anything.
> the problem with pointers is that they exist even after you finish executing the program.so sometimes you might have to hardboot the system in order to free the memory.
Under Unix all resources used by a process are freed when it terminates; no need to reboot. Remember: Unix is an operating system :-)
i know my friend who used to invoke a General Protection Fault while running a C++ Program in DOS/Windows.
This used to happen every second run.
This used to happen every second run.
amorousdonjuan: Right, 'General Protection Fault' is the translation of 'Segmentation fault' in the DOS/Windows world. I just wanted to point out that llagreca does not have to worry burning the whole system with a buggy program if he/she is working under Unix, because the OS will not allow it to corrupt system memory or leave orphined memory after termination.
The best way to find out is to run the program in a debugger with a file that causes the segfault. There are several good graphical front-ends for the system's debugger available -- I assume you code under Unix --, my favourite: ddd