When running my code, it crashes and says "Segmentation fault".
However, when I run through it in gdb, it crashes due to a SIGABRT error not a SIGSEGV.
Are there other signals that also "map" to a general Segmentation fault error on the terminal?
abort() sends the calling process the SIGABRT signal, this is how SIGABRT or Signal 6 is generated. Also, most "assert" implementations make use of SIGABRT in case of a failed assert.
abort() is usually called by library functions which detect an internal error or some seriously broken constraint. For example malloc() will call abort() if its internal structures are damaged by a heap overflow.
SIGSEGV or Signal 11, officially know as "segmentation fault", means that the program accessed a memory location that was not assigned. That's usually a bug in the program. So if you're writing your own program, that's the most likely cause. otherwise I do not see any other signal will create segmentation fault in a program.
Related
I have written a phone book and my person input like "name-number-type" and if the user give "_" or any other character that is not "-" as seperator the program will crash by seg. fault because i used strtok() to split input. Also if the user gives number that is not proper input like 1232414eree224, my program will crash again. So i just think that if i handle the seg. fault signal in os level may be i can fix this bug. I know that i can write a controller function but i am searching for a new way to deal with like that error. Is there any possible way to do this?
So i just think that if i handle the seg. fault signal in os level may
be i can fix this bug.
It does not seem like a good idea at all, a SIGSEGV handler is not intended to ignore or try to fix the error, they are used to consistently exit your process, e.g. remove the used heap so that there are no memory leaks, to write in a log reporting the error ...
In addition, in the POSIX standard:
The behavior of a process is undefined after it returns normally from
a signal-catching function for a [XSI] SIGBUS, SIGFPE, SIGILL, or
SIGSEGV signal that was not generated by kill(), [RTS] sigqueue(), or
raise().
When I try to do the command "/bin/kill -11 0" on bash, tcsh or zsh, it doesn't segfault but when I try to do it in mine, it does.
So I must have something I didn't handle.
Do you know what it can be ?
Thanks.
Your program doesn't actually segfault when it sends itself signal 11.
If the execution of a programs results in a "segment fault" (that is, the program performs an illegal memory reference), then the operating system sends the program SIGSEGV (signal 11 on Linux). The program cannot distinguish between a SIGSEGV sent by the operating system as the result of a program fault and a SIGSEGV sent by a call to raise or kill, possibly from another process, so it will respond as though there had been a real program error.
If you want to protect your shell from signals sent to pid 0 from a child process, you need to make sure that your child processes are in a different process group by calling setpgid in the child after the fork.
By default, a program is terminated by SIGSEGV. By default, the shell which invoked the program will then report that the program was terminated by SIGSEGV. This is popularly known as "segfaulting", but as indicated above, it might not have been the result of a real program fault.
If you want your program to do something else, you have to catch signal SIGSEGV with a signal handler; for example, if some cleanup needs to be done before the program terminates. Most shells (and databases) do that, but it is rarely necessary in user code.
Note: Signal 11 is SIGSEGV on Linux, but there is no guarantee that SIGSEGV will be signal 11 on a different OS (or even in some future version of Linux). You should always use the name of the signal rather than the number.
I'm compiling a C program with flags "-Wall -W -pedantic -O0 --coverage" (GCC version 4.8.2). However when a segmentation fault happens on that program I can't extract the coverage, because I don't have the .gcda file...
Does anyone know how can I use gcov even when a segmentation fault happens?
Thanks.
Does anyone know how can I use gcov even when a segmentation fault happens?
The coverage files are normally written by atexit handler, which requires program to call exit(). That does not happen when the program dies with SIGSEGV, which is why you don't get the .gcda file in that case.
The best solution is to fix whatever bug is causing SIGSEGV in the first place.
Alternatively, you could install a SIGSEGV handler, and call exit() from it. This is not guaranteed to work. For example, if your program hit SIGSEGV due to heap corruption, it may deadlock or crash again when exit calls global destructors.
Another possible solution is to run the program under GDB, and call __gcov_flush() from the debugger when you get SIGSEGV.
I am teaching myself to use gdb and am running some random tests. It may be worth mentioning that I am using a portable installation of MinGW on Windows 7 x64. I've created a program which I know results in a stack overflow, and as I run through it in gdb I first get two SIGSEGV signals (no surprise), and then it exits (again no surprise) with code 030000000375.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program exited with code 030000000375.
Curiosity getting the best of me... what the heck is that code? I googled it and found very little.
Thanks!
UPDATE: For reference I tried the same program on Ubuntu, and the results are slightly different:
Program received signal SIGSEGV, Segmentation fault.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
gdb prints out the exit code in octal format. Not obvious, but indicated by the leading 0.
So 030000000375 is 0xC00000FD in hex, which makes the code look much more common to a windows programmer.
0xC00000FD is STATUS_STACK_OVERFLOW and should be defined in ntstatus.h.
I am getting segmentation fault despite having a signal handler for SIGSEGV. The first time data is written to protected memory, I can see that signal handler is called, but before the signal handler exits, segmentation fault appears.
What can be causing it? Isn't my SIGSEGV handler supposed to catch all the segmentation faults?
I could see where if the segmentation fault is related to the stack pointer accessing memory where it's not allowed by the OS, then you won't be able to make any calls with the current stack pointer for your process ... that includes calls to signal handlers. In other words the compiler-created prologue for your signal handler function has to setup an activation record on the stack ... if the stack pointer itself is invalid, then that won't be possible. One way this could happen is by overflowing a memory array that then writes-over the activation record for the currently executing function.
You can define another area of memory to be used as a stack for your signal handlers though sigaltstack(), and then setting the SA_ONSTACK option in sigaction() for the signal. This might be something you might want to try.
Finally, you could also run into issues if you're using non-async-safe functions or somehow are accessing pointers or memory that is outside the memory segment allotted to your process by the OS in your signal handler.
If your signal handler in turn provokes another signal that of course is not caught by your signal handler as you would then have a kind of infinite loop.