EDIT: Clarifying.
fout is is a FILE*. (I thought this was irrelevant since that line clearly compiles)
there is A LOT of code above these last few lines; I guess I could dump them all but I imagine you're not overly interested in debugging my stuff. I'm more interested, generally, in what could possibly occur that would segfault at return 0 but not before.
Warning: My C is terrible.
I've got a C program which, from the likes of it, just wants to segfault. I'll spare you the other, irrelevant details, but here's the big picture:
My code:
//...other code
printf("finished \n");
fclose(fout);
printf("after fclose \n");
return 0;
The output:
finished
after fclose
Segmentation fault
I'm compiling with GCC, -std=c99.
My question:
How the heck is this even possible? What should I be looking at, that may be causing this (seemingly random) segfault? Any ideas?
Much thanks!
Whatever the return is going back to is causing the fault. If this code snippet is in main(), then the code has inflicted damage to the stack, most likely by exceeding the bounds of a variable. For example
int main ()
{
int a [3];
int j;
for (j = 0; j < 10; ++j)
a [j] = 0;
return 0;
}
This sort of thing could cause any of a number of inexplicable symptoms, including a segfault.
Since it's probably a stack corruption related problem, you could also use a memory debugger to locate the source of the corruption, like valgrind.
Just compile using gcc -g and then run valgrind yourprog args.
Does "Hello world!" program seg fault? If so then you have a hardware problem. If not then you have at least one problem in the code you're not showing us!
Compile your program with the debug flag gcc -g and run your code in gdb. You can't always trust the console to output "Segmentation fault" exactly when problematic code is executed or relative to other output. In many cases this will be misleading -- you will find debugging tools such as gdb extremely useful.
Related
I am trying to "debug" this program using GDB debugger. I get the Segmentation fault (core dumped) when I execute the program.
This is my first time using GDB, so I do not really know what command to use or what to expect.
EDIT: I know what the error is. I need to find it using the GDB Debugger
This is the code:
#include <stdio.h>
int main()
{
int n, i;
unsigned long long factorial = 1;
printf("Introduzca un entero: ");
scanf("%d",n);
if (n < 0)
printf("Error! Factorial de un numero negativo no existe.");
else
{
for(i=0; i<=n; ++i)
{
factorial *= i;
}
printf("Factorial de %d = %llu", n, factorial);
}
return 0;
}
Here is the problem:
scanf("%d",n);
As you wrote, n is declared as a variable of type int. What you want to do is to pass the address of n instead of n itself into the function.
scanf("%d", &n);
To better understand the implementation of scanf(), check out stdio.h.
Also, set n = 1. Or otherwise the variable factorial will remain 0 regardless how many loops you've gone through.
EDIT: what you are trying to do to is to access a memory location passed in by the user, which is highly likely to map to a memory location that belongs to a completely different process or even OS. The segmentation fault is generated simply because the location is not accessible. What you can do in gdb is using bt in the gdb to a stack trace of segmentation fault.
I know what the error is. I need to find it using the GDB Debugger
You need to read the documentation of gdb (and you should compile your source code with all warnings and debug info, e.g. gcc -Wall -Wextra -g with GCC; this puts DWARF debug information inside your executable).
The GDB user manual contains a Sample GDB session section. You should read it carefully, and experiment gdb in your terminal. The debugger will help you to run your program step by step, and to query its state (and also to analyze core dumps post-mortem). Thus, you will understand what is happening.
Don't expect us to repeat what is in that tutorial section.
Try also the gdb -tui option.
PS. Don't expect StackOverflow to tell you what is easily and well documented. You are expected to find and read documentation before asking on SO.
This is the C code that I am compiling:
#include <stdio.h>
#include <stdlib.h>
int main(){
long val=0x41414141;
char buf[20];
printf("Correct val's value from 0x41414141 -> 0xdeadbeef!\n");
printf("Here is your chance: ");
scanf("%24s",&buf);
printf("buf: %s\n",buf);
printf("val: 0x%08x\n",val);
if(val==0xdeadbeef)
system("/bin/sh");
else {
printf("WAY OFF!!!!\n");
exit(1);
}
return 0;
}
Here, I am expecting an overflow in long val if user inputs string 24 character long, changing the value in val. But it just doesn't get overflowed even if string is long enough. Can someone please explain this behaviour?
I am on macOS. This is what gcc -v spits out:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Also, after googling a bit I tried gcc with these flags:
gcc -g -fno-stack-protector -D_FORTIFY_SOURCE=0 -o overflow_example overflow_example.c
still, the result is same.
This code is part of narnia wargame challenge on overthewire. I managed to crack this challenge on their remote shell, where it was behaving as expected. Now, I am trying to reproduce this same challenge on my local system and facing this issue. Please help.
EDIT: For all the people yelling out about UB: like I said, this was one of the challenge to be solved on overthewire, so it cannot have UB. There are some blogs (here's on I found) that provide walkthrough for this challenge with reasonable logical explanation for why the code behaves the way it does, with which I agree. I also understand that the compiled binary is platform dependent. So, what am I to do to produce this binary with potential overflow on my local system?
It's undefined behavior because C functions do not check whether an argument is too big for its buffer or not.
Apparantly the variables get laid out differently on the stack on your mac.
Wrapping them in a struct will ensure that they are placed in the order you want.
Since there is the possibility of padding, let's turn it off. For gcc, the precompiler directe #pragma pack controls struct packing.
int main(){
#pragma pack(1)
struct {
char buf[20];
long val=0x41414141;
} s;
#pragma pack()
printf("Correct val's value from 0x41414141 -> 0xdeadbeef!\n");
printf("Here is your chance: ");
scanf("%24s",&s.buf);
printf("buf: %s\n",s.buf);
printf("val: 0x%08x\n",s.val);
if(s.val==0xdeadbeef)
system("/bin/sh");
else {
printf("WAY OFF!!!!\n");
exit(1);
}
return 0;
}
I'm not sure what you mean.
1) Are you concerned that your input string will create a number that will be too big to store in a long. This will not happen the number will simply wrap round.
2) Are you concerned that you'll read to memory beyond the bounds of buf? In C this will produce undefined behavior not necessarily a crash.
buf is on the stack (could be just as well on the heap) so you can just keep writing to memory from the address where buf starts. The compiler will generate code that will not do a bounds check for you. So if you go beyond the 20byte you'll eventually start overwriting other parts of memory that do not belong block of memory you've set aside for buf.
Can I detect a possible segmentation fault at compile-time?
I understand the circumstance of a segmentation fault. But I am curious if GCC as a compiler has some flags to check for the basic scenarios resulting in segmentation faults.
This would help enormously to take precautions before releasing a library.
Can I detect a possible segmentation fault at compile time?
Sometimes, but no, you can't flawlessly detect these scenarios at compile time. Consider the general case in this C code:
volatile extern int mem[];
void foo (int access)
{
mem[access];
}
A compiler would be too noisy if it were to warn about this access at compile time, the code is valid C and a warning is, in general, inappropriate. Static analysis can't do anything with this code unless you have a mechanism for whole-program or link-time analysis.
An additonal optimization flag in GCC 4.8 which can sometimes catch a few out-of-bounds access in loops is `-faggressive-loop-optimizations'. This found a number of issues in the SPEC benchmark suite last year (http://blog.regehr.org/archives/918)
I understand the circumstance of segmentation fault. But i am curious if GCC as a compiler has some flags to check for the basic scenarios resulting in segmention faults.
GCC 4.8 comes with an address sanitizer which can help catch some of these run-time only issues (out of bounds/use-after-free bugs). You can use it with
-fsanitize=address.
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Debugging-Options.html#Debugging-Options
GCC 4.9 (which will be released within the next few months) comes with an undefined behaviour sanitizer and more aggressive optimization of NULL pointer paths, which might help you catch some more issues. When it comes, it will be available with -fsanitize=undefined
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options
Note however that neither of these are "compile-time" solutions, they both rely on instrumenting the binary and performing run-time checks.
Yes, there are ways of detecting some faults that may cause runtime errors such as segmentation faults. Those ways are called warnings. Many warnings messages are places where you have undefined behavior, and undefined behavior is often the leading cause of runtime crashes.
When I build, I always use the -Wall, -Wextra and -pedantic flags.
Other than that, there are really no good way of detecting all places that may cause segmentation faults (or other runtime errors), except strict coding guidelines, code reviews and plenty of testing.
gcc -Wall -Werror as mention by Joachim Pileborg are very good ideas. You could also use another compiler maybe. some reports more memory issues. I think you can not do a lot more at compile time.
At running time, I highly recommend Valgrind, which is a amazing tool for detecting memory issues. (don't forget to compile with the -g option)
Can I detect a possible segmentation fault at compile-time?
Yes, it is possible. Unfortunately, it is very limited what the compiler can do. Here is a buggy code example and the output from gcc and clang:
#include <stdlib.h>
int main() {
int a[4];
int x, y;
a[5]=1;
if(x)
y = 5;
x = a[y];
int* p = malloc(3*sizeof(int));
p[5] = 0;
free(p);
free(p);
}
For this buggy code, gcc -Wall -Wextra corrupt.c gives
corrupt.c: In function ‘main’:
corrupt.c:13:1: warning: control reaches end of non-void function [-Wreturn-type]
corrupt.c:6:7: warning: ‘x’ is used uninitialized in this function [-Wuninitialized]
clang catches more:
corrupt.c:5:5: warning: array index 5 is past the end of the array (which contains 4 elements) [-Warray-bounds]
a[5]=1;
^ ~
corrupt.c:3:5: note: array 'a' declared here
int a[4];
^
corrupt.c:6:8: warning: variable 'y' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if(x)
^
corrupt.c:8:11: note: uninitialized use occurs here
x = a[y];
^
corrupt.c:6:5: note: remove the 'if' if its condition is always true
if(x)
^~~~~
corrupt.c:4:13: note: initialize the variable 'y' to silence this warning
int x, y;
^
= 0
corrupt.c:6:8: warning: variable 'x' is uninitialized when used here [-Wuninitialized]
if(x)
^
corrupt.c:4:10: note: initialize the variable 'x' to silence this warning
int x, y;
^
= 0
3 warnings generated.
I believe the above code example gives you insight what to expect. (Even though I tried, I could not get the static analyzer in clang to work.)
This would help enormously to take precautions before releasing a library.
As you can see above, it won't be an enormous help, unfortunately. I can only confirm that instrumentation is currently the best way to debug your code. Here is another code example:
#include <stdlib.h>
int main() {
int* p = malloc(3*sizeof(int));
p[5] = 0; /* line 4 */
free(p);
p[1]=42; /* line 6 */
free(p); /* line 7 */
}
Compiled as clang -O0 -fsanitize=address -g -Weverything memsen.c. (GCC 4.8 also has address santizier but I only have gcc 4.7.2.) The output:
==3476==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000f004 at pc 0x4887a7 bp 0x7fff9544be30 sp 0x7fff9544be28
WRITE of size 4 at 0x60200000f004 thread T0
#0 0x4887a6 in main /home/ali/tmp/memsen.c:4
[...]
Awesome, we know what went wrong (heap-buffer-overflow) and where (in main /home/ali/tmp/memsen.c:4). Now, I comment out line 4 and get:
==3481==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000eff4 at pc 0x4887d7 bp 0x7fff27a00d50 sp 0x7fff27a00d48
WRITE of size 4 at 0x60200000eff4 thread T0
#0 0x4887d6 in main /home/ali/tmp/memsen.c:6
[...]
Again, we see what went wrong and where. Finally, I comment out line 6.
==3486==ERROR: AddressSanitizer: attempting double-free on 0x60200000eff0 in thread T0:
#0 0x46dba1 in free /home/ali/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:65
#1 0x48878c in main /home/ali/tmp/memsen.c:7
[...]
Also caught the problem.
If your code has tests, or at least you can run your code with different inputs on your machine before releasing the library, you could probably track down a significant portion of the bugs. Unfortunately, it is not a compile-time solution and you probably don't want to release instrumented code (code compiled with -fsanitize=* flag). So if the user runs your code with an input that triggers a bug, the program will still crash with a segmentation fault.
I have a program problem for which I would like to declare a 256x256 array in C. Unfortunately, I each time I try to even declare an array of that size (integers) and I run my program, it terminates unexpectedly. Any suggestions? I haven't tried memory allocation since I cannot seem to understand how it works with multi-dimensional arrays (feel free to guide me through it though I am new to C). Another interesting thing to note is that I can declare a 248x248 array in C without any problems, but no larger.
dims = 256;
int majormatrix[dims][dims];
Compiled with:
gcc -msse2 -O3 -march=pentium4 -malign-double -funroll-loops -pipe -fomit-frame-pointer -W -Wall -o "SkyFall.exe" "SkyFall.c"
I am using SciTE 323 (not sure how to check GCC version).
There are three places where you can allocate an array in C:
In the automatic memory (commonly referred to as "on the stack")
In the dynamic memory (malloc/free), or
In the static memory (static keyword / global space).
Only the automatic memory has somewhat severe constraints on the amount of allocation (that is, in addition to the limits set by the operating system); dynamic and static allocations could potentially grab nearly as much space as is made available to your process by the operating system.
The simplest way to see if this is the case is to move the declaration outside your function. This would move your array to static memory. If crashes continue, they have nothing to do with the size of your array.
Unless you're running a very old machine/compiler, there's no reason that should be too large. It seems to me the problem is elsewhere. Try the following code and tell me if it works:
#include <stdio.h>
int main()
{
int ints[256][256], i, j;
i = j = 0;
while (i<256) {
while (j<256) {
ints[i][j] = i*j;
j++;
}
i++;
j = 0;
}
printf("Made it :) \n");
return 0;
}
You can't necessarily assume that "terminates unexpectedly" is necessarily directly because of "declaring a 256x256 array".
SUGGESTION:
1) Boil your code down to a simple, standalone example
2) Run it in the debugger
3) When it "terminates unexpectedly", use the debugger to get a "stack traceback" - you must identify the specific line that's failing
4) You should also look for a specific error message (if possible)
5) Post your code, the error message and your traceback
6) Be sure to tell us what platform (e.g. Centos Linux 5.5) and compiler (e.g. gcc 4.2.1) you're using, too.
This is a mad-hack, but I am trying to deliberately cause a segfault at a particular point in execution, so valgrind will give me a stack trace.
If there is a better way to do this please tell me, but I would still be curious to know how to deliberaly cause a segfault, and why my attempt didn't work.
This is my failed attempt:
long* ptr = (long *)0xF0000000;
ptr = 10;
I thought valgrind should at least pick up on that as a invalid write, even if it's not a segmentation violation. Valgrind says nothing about it.
Any ideas why?
EDIT
Answer accepted, but I still have some up-votes for any suggestions for a more sane way to get a stack trace...
Just call abort(). It's not a segfault but it should generate a core dump.
Are you missing a * as in *ptr = 10? What you have won't compile.
If it does, somehow, that of course won't cause a seg-fault, since you're just assigning a number. Dereferencing might.
Assuming dereferencing null on your OS results in a segfault, the following should do the trick:
inline void seg_fault(void)
{
volatile int *p = reinterpret_cast<volatile int*>(0);
*p = 0x1337D00D;
}
Sorry for mentioning the obvious but why not use gdb with a breakbpoint and then use backtrace?
(gdb) b somewhere
(gdb) r
(gdb) bt
As mentioned in other answers you can just call abort() if you want to abnormally terminate your program entirely, or kill(getpid(), SIGSEGV) if it has to be a segmentation fault. This will generate a core file that you can use with gdb to get a stack trace or debug even if you are not running under valgrind.
Using a valgrind client request you can also have valgrind dump a stack trace with your own custom message and then continue executing. The client request does nothing when the program is not running under valgrind.
#include <valgrind/valgrind.h>
...
VALGRIND_PRINTF_BACKTRACE("Encountered the foobar problem, x=%d, y=%d\n", x, y);
Wouldn't it be better to send sig SEGV (11) to the process to force a core dump?
Are you on x86? If so then there is actually an opcode in the CPU that means "invoke whatever debugger may be attached". This is opcode CC, or more commonly called int 3. Easiest way to trigger it is with inline assembly:
inline void debugger_halt(void)
{
#ifdef MSVC
__asm int 3;
#elif defined(GCC)
asm("int 3");
#else
#pragma error Well, you'll have to figure out how to do inline assembly
in your compiler
#endif
}
MSVC also supports __debugbreak() which is a hardware break in unmanaged code and an MSIL "break" in managed code.