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.
Related
I'm trying to compile my homework and I needed to recreate strlwr() (only available on Windows), and I'm getting this error:
Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
I'm using this strlwr().
I found the code for strlen-avx2.S, but I can't find it in my system.
If I use this one, there's no mention of strlen-avx2.S, but still getting segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
0x000055555555532d in strlwr (str=0x0) at parser.c:36
36 while (*p) {
I am using gdb to find out why I am getting a seg fault. I run the command gba myProg core so I can see the core dump from the seg fault. The core dump reads as follows.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __GI__IO_fwrite (buf=0x7f32040167a0, size=1, count=2, fp=0x0) at iofwrite.c:37
37 iofwrite.c: No such file or directory.
[Current thread is 1 (Thread 0x7f3209bac700 (LWP 20157))]
I'm having a hard time figuring out the error message. It seems to be saying that the seg fault is due to iofwrite.c but I can't seem to find any information on such a file. I assume it relates to fwrite.
You are passing a NULL fp to fwrite(). It's impossible to answer more completely without code.
I had encounted this question too, the reason was my output file name is invalid.
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.
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.
My program (it is an smtp server program, tested by jmeter) run without any problem when it is run by valgrind.
But failed (got SIGABRT) finally, if it is running without valgrind or run within 'gdb' debugger.
I've tested all of the valgrind's tools (memcheck,helgrind,drd,massif) but no one reported any problem. I haven't found any memory leaks (checked by mtrace() ).
I've got the following :
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7101b70 (LWP 1639)]
0xb776d416 in __kernel_vsyscall ()
the backtrace show various locations which changend run by run. The problems always allude to malloc() or free() (and always correlate with a string (char array) )
The question is: how can I found the problem, if valgrind and mtrace did not show any problem and the program can run without stoppage (within valgrind) in an endless jmeter test loop?