ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
main(int argc, char *argv)
printf("How old are you?\n");
result = scanf(" %d", &age);
printf ("result was %d\n", result);
printf("You are %d years old.", age);
Distribution: Mac OS X Leopard 10.6.2, Windows 2003 Server/Vista/7/XP/2000/NT/98, Ubuntux64, CentOS4.8/5.4
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!
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
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:
and get a 0 back, it means the core fill won't be written. You can change this by using the command
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.