LinuxQuestions.org - segmentation fault (core dumped)

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - segmentation fault (core dumped) - what??? (https://www.linuxquestions.org/questions/programming-9/segmentation-fault-core-dumped-what-508083/)

segmentation fault (core dumped) - what???

I am learning the C language so I wrote a simple little program that would spit back my age.

Code:

#include <stdio.h>

main()



{

    int age;

    printf("How old are you?\n");

    scanf(" %d", age);

    printf("You are %d years old.", age);

}

I then run

Code:

cc filename.c -o age

I execute the file and then I get the segmentation fault (core dumped). What does this mean?

Code:

#include <stdio.h>

main()

{

    int age;

    printf("How old are you?\n");

    scanf(" %d", &age);

    printf("You are %d years old.", age);

}

Whoops! That fixed the problem! Thanks!

Now I must expand my code to only accept numbers or else it will loop again until the user inputs an age. That's my next challenge

Quote:

Originally Posted by Micro420

I execute the file and then I get the segmentation fault (core dumped). What does this mean?

A segmentation fault occurs when a program tried to access memory it has not been told it can use by the OS. Memory is split into segments. If a program tries to read or write a memory address from a segment it has not been allocated, the OS sends a signal (SIGSEGV) to the process, telling it "naughty boy!", and by default the process falls over with this error message.

"core dumped" means the state of the program is written to a file called "core". This is helpful for debuggers which can read the core file and work out where the program crashed, the values in the variables, registers, what was on the stack and so on.

When you use scanf, you have to pass the memory address into which the input will be written by the scanf function. You passed the value of the integer "age". age is probably 0 or some random number at the point scanf gets it (it hasn't been assigned to, so officially it's value is undefined). This random value is almost certainly not a memory address in a segment which has been allocated to the program, hence the segmentation fault. The correction paulsm4 provided shows the syntax specifying the address of the integer "age".

Addresses and pointers to variables is a tricky subject to start with. Don't worry - you'll get a lot of core dumps before you think you understand it, and then a whole lot more before you actually understand it. :)

Hi -

matthewg42 gave a very good explanation for both "What is a 'segmentation violation'?" and "Why do I need to use the funny '&' operator in scanf?". Please feel free to ask any follow-on questions you might have.

This post is in reply to your "how do I expand my code" question.

Obviously, we can't do your homework for you. But the code in red suggests one possible solution to the problem. Run the code, read the "man" page for scanf ... and see if it leads you where you want to go.

The code in blue is "just good to have" - I would suggest using the full signature for "main()" and always passing a return value whether or not you actually need to. It's just, IMHO, good form.

Code:

#include <stdio.h>



int

main(int argc, char *argv[])

{

    int age;

    int result;



    printf("How old are you?\n");

    result = scanf(" %d", &age);

    printf ("result was %d\n", result);

    printf("You are %d years old.", age);



    return 0;

}

Hope that helps .. PSM

Thanks for your detailed explanation, Matthewg42. I don't know all the little details, but what you're trying to say is that the input was being stored improperly, correct? Just out of curiosity, where is this core dump file so that I can debug? I'm just curious to see what is in this file. I've read a little bit about arrays and I understand the concepts, but I'm not sure if I am ready to apply them into something practical. Will keep trying different things.

paulsm4, thanks for the suggestion, but I haven't gotten to the result = yet. I'm still learning the if-else, while, case, and conditional loops. Supposedly I should be be able to only accept numbers and reject characters and symbols. I'll have to think about this logically for awhile. :) I'm trying to do this without referencing my C programming book. By the way, I am reading this book called Absolute Beginners Guide to Programming in C. Best C programming book I have read so far!

Quote:

Originally Posted by Micro420

Thanks for your detailed explanation, Matthewg42. I don't know all the little details, but what you're trying to say is that the input was being stored improperly, correct?

More or less :)

Quote:

Originally Posted by Micro420

Just out of curiosity, where is this core dump file so that I can debug? I'm just curious to see what is in this file.

The file will be in the directory in which you executed the program, although there is a shell setting which might prevent it actually appearing. If you type:

Code:

ulimit -c

and get a 0 back, it means the core fill won't be written. You can change this by using the command

Code:

ulimit -c unlimited

This setting only affects the shell you are in until that shell terminates. Once this is set, re-run the program and the core file should be there when you have a core dump happen.

To use the core dump, you need to use the debugger. This is usually gdb. It looks ugly if you're used to a graphical debugger interface, but it's actually quite flexible. There are plenty of graphical front-ends to it, but it pays dividends to learn gdb directly.

To use the debugger, you need to make sure that you compiled your program using the -g option to gcc. This includes debugging symbols in the executable, and allows gdb to know what line of sourcecode is being executed for a given part of the binary.

So, in summary:

Code:

gcc -g yourprogram.c -o yourprogram

ulimit -c unlimited

./yourprogram

(core dump happens, core file is created)

gdb yourprogram core

At this point you can enter gdb commands like "bt" to print a backtrace of the functions which were being executed when the error occurred.