I am getting a segmentation fault right after I am creating a thread. The thread that I am creating is globally defined list. gdb descriptioncode Stdout does not print the print statement right after pthread_create. Would appreciate any help
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.
This question already has answers here:
Why do I get a segmentation fault when writing to a "char *s" initialized with a string literal, but not "char s[]"?
(19 answers)
Closed 7 years ago.
Consider this simple code fragment :
{
if(fork())
{
printf("Parent terminated\n");
}
else
{
char *s = "hello world";
*s = 'H';
printf("child terminated\n");
}
wait(NULL);
return 0;
}
When I compile it I dont get a segmentation fault error as we expect while assigning to *s
The output is :
Parent Terminated ( without printing child terminated)
Now if I remove the two lines char *s=......'H' I get the normal output .Can someone please explain this
First of all, you aren't guarenteed to get a segmentation fault, or any defined behavior, for triggering undefined behavior, such as modifying a string literal. Though on Linux, string literals are put into read-only memory, so modifying them on Linux will usually result in a segmentation fault.
So why doesn't this code trigger a segfault? It does, but you just don't see it, because you forked.
The "Segmentation Fault (core dumped)" message is printed by your shell (ex. bash), when it detects, by calling wait, when the process it spawned terminates with a SIGSEGV (segfault) signal. However, your shell will not receive any notifications about child processes exiting; your parent process will.
Your parent process calls wait to wait and get the exit code when it terminates. If you weren't ignoring the exit code by passing in NULL to wait, you'd probably see that the exit code is -11, or -SIGSEGV.
So it is segfaulting; your parent process is just ignoring the child's notification that it segfaulted.
Firstly, what others said is correct: the behavior is undefined and you cannot depend on any behavior in particular when doing this.
However, I suspect what's happening is that the child actually is having a segmentation fault. However, the familiar "Segmentation fault" message you see in your terminal is actually printed by your shell when something you run seg faults.
But, since this is a child of something you ran, your shell didn't notice. If you have configured core dumps (e.g. ulimit -c unlimited) I expect you will find a core file from the seg faulted child process.
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 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.