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.
deiussum - is correct: your program is crashing because you're doing an assignment using a pointer variable ("Second") that was never initialized.
You would have spotted the problem immediately had you tried running your program inside a debugger (for example, "gdb").
The debugger is your friend: please consider familiarizing yourself with one of the many debuggers out there (this is heresy in a Linux forum, but I'd recommend starting with Visual Studio to familiarize yourself with debuggers in general...)
means that Second is a pointer to a TEST, which you have defined as a structure.
In other words, Second is a simple integer-like variable, currently unitialized, whose value will be understood to be the address of a TEST.
The value of Second is undefined ... it is garbage ... and fortunately for you it points to a "bogus" memory address, resulting in the segmentation-fault. What you must do, with any pointer-type variable is:
Always ensure that the pointer is properly initialized before you use it. You should know at all times that any pointer either points to a valid object or it is known to be NULL. ("NULL" is a special value that "points to nothing.")
When you allocate an object, you must always free that object.
When you do free the object, I strongly recommend that you set the pointer back to NULL. This preserves the you-enforced rule that "the value in the pointer must be valid or it must be NULL." Even if some would argue that it's unnecessary or "inefficient," I assure you that the discipline will serve you well.
1. If you do a "malloc()", you need to do a corresponding "free()".
2. If you do a "new", then you need to do a corresponding "delete".
3. "malloc()/free()" and "new/delete" are *different things", you *cannot* mix'n'match them.
Malloc and free are C library functions; they can be called from C, C++ (or any other language that can interface to the standard library).
"New" and "delete" are C++ operators; they can be used *only* in a C++ program.
* When you do free the object, I strongly recommend that you set the pointer back to NULL. This preserves the you-enforced rule that "the value in the pointer must be valid or it must be NULL." Even if some would argue that it's unnecessary or "inefficient," I assure you that the discipline will serve you well.
I was using the same style in C. I wish to recollect an incident in the recent past.
As you see, the pointer was freed two times, but since the ptr was re-init to NULL, the second free didnot
have any effect. If it was not re-initialized, segmentation violation would have occured.
Then the problem (second freeing) would have been found out and fixed.
Now my question is, is it OK to re-initialize a pointer to NULL, because it can supress the problems like the one
i mentioned above. Does it not result in an unclean code (working one though).........
One good reason for initializing to NULL after freeing memory is that it makes it easy to test if the pointer is valid. If you leave a dangling pointer, there is no easy way to know that it is dangling until you use it and it causes problems.
I think sundialsvcs advice is good advice. Any "habit" that forces you to *think*; any "convention" that takes the implicit ("a freed pointer has become undefined") and makes it *explicit* ("a null pointer cannot be used") - is definitely a Good Thing.
I think opening *any* door to *any* potential bugs is a Bad Thing.
I would suggest that sundialsvcs's advice is a good way to minimize the chances of accidentally using a freed (or uninitialized) pointer (like Yerp inadvertantly did).
I would further suggest that sundialsvcs's advice is *also* applicable to the *second* kind of bug that hk suggested. If the pointer is always NULL whenever the pointer variable is undefined, then you can easily prevent double-freeing with the following:
You'll notice that this *prevents* the bug; it doesn't just "detect" it (said detection being a program crash and a core dump). In my book, "prevention" trumps "detection" every time.
IMHO .. Paul Santa Maria
"deiussum" and I were typing in essentially the same answer together at the same time. We both seem to be in agreement with sundialsvcs :-)
I had the char *C; notation in my mind, and used them as the same...despite my experience with malloc, calloc, realloc, new, delete, etc...
apparently this is what happens when I don't program for over 6-months and come back to it
Thats weird. I copied ur program and executed. It dumped core for me.....
Extract from man free
free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs. If ptr is NULL, no operation is performed.
Yes "undefined behavior" -- that seems to be the point of replies to your first message in this thread.
If you free twice, it may crash right there. Or it may run "fine". Or it may subly corrupt dynamic memory management ("the heap"), with consequences that manifest ten million instructions later. Or not, until you install your software at a customer's
BTW, to track down dynamic memory problems, I found Valgrind extremely helpful.