Segmentation Fault before faulty code is ever reached?

This is a discussion on Segmentation Fault before faulty code is ever reached? within the C Programming forums, part of the General Programming Boards category; Here I have a segmentation fault caused by my function insert. It's not like one I've seen before though. Run ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    182

    Segmentation Fault before faulty code is ever reached?

    Here I have a segmentation fault caused by my function insert. It's not like one I've seen before though. Run insert once and it works fine. Run it twice and a segmentation fault occurs before insert even gets a chance to run. Could someone explain this?

    Code:
    #include <stdio.h>
    #include <stdlib.h>
    
    struct listnode {
    	int num;
    	struct listnode *nextPtr;
    };
    
    typedef struct listnode ListNode;
    
    void insert( ListNode **sPtr, int number );
    void display( ListNode **sPtr );
    
    
    
    int main()
    {
    	ListNode *ptr = NULL;
    
    	insert( &ptr, 2 );	
    	insert( &ptr, 3 );
    //	insert( &ptr, 111 );
    	display( &ptr );
    	return 0;
    }
    
    
    
    
    void display( ListNode **sPtr )
    {
    	ListNode *currentPtr = NULL;
    	currentPtr = *sPtr;
    
    	while ( currentPtr != NULL ) {
    		printf( "%10d", currentPtr->num );
    		currentPtr = currentPtr->nextPtr;
    	}
    }
    
    
    
    void insert( ListNode **sPtr, int number )
    {
    	ListNode *newPtr = NULL;
    	ListNode *currentPtr = NULL;
    	ListNode *previousPtr = NULL;
    // -------------This Test Statement is Never Reached when there are two inserts --------
    printf( "test" );
    
    	newPtr = malloc( sizeof( ListNode ) );
    	newPtr->num = number;
    	newPtr->nextPtr = *sPtr;
    
    	if ( newPtr != NULL ) {
    		printf( "hello" );
    		if ( *sPtr == NULL ) {
    			*sPtr = newPtr;
    		}
    		else {
    			currentPtr = *sPtr;
    
    			while ( currentPtr->nextPtr != NULL && currentPtr->num < number ) {
    				previousPtr = currentPtr;
    				currentPtr = currentPtr->nextPtr;
    			}
    			previousPtr->nextPtr = newPtr;
    			newPtr->nextPtr = currentPtr;
    		}
    	}
    }

  2. #2
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,047
    any luck with gdb in pinpointing the source of the problem?

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,166
    The problem is in your while loop. On the second call of your function (which is the first time the while loop is executed) currentPtr->nextPtr will be NULL, so the value of previousPtr will be NULL on completion of the loop. The first line after that loop is dereferencing previousPtr (i.e. dereferencing a NULL pointer).

    It is also a good idea to check that newPtr (returned from malloc()) is non-NULL before setting newPtr->num and newPtr->nextPtr.

  4. #4
    Registered User
    Join Date
    May 2006
    Posts
    182
    >>itCbitC
    No, I haven't figured GDB out yet. It's on my todo list

    >>Grumpy
    That makes some sense. Why am I getting a segmentation fault before the first instance gets a chance to run? printf( "test" ) should run at least once. It does run when my main body has only one insert. But not even once when it has two or more inserts.

  5. #5
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Your belief that "test" appears on your screen instantaneously is mistaken. If you want to see what's written to the screen, you should use fflush(stdout) [although usually putting a \n in the printed string is enough to force a flush as well].

  6. #6
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,047
    heed tabstop's advice, string "test" isn't printed due to buffering of stdout, and problem lies with line that's trying to access elements of a null pointer as in
    Code:
    previousPtr->nextPtr = newPtr;
    Last edited by itCbitC; 01-09-2009 at 10:53 PM.

  7. #7
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,420
    > No, I haven't figured GDB out yet. It's on my todo list
    Actually, it's on your do now list.
    It's a good idea to get plenty of debug practice in while your problems are relatively trivial (aka, the ones we can spot just by reading the code).

    In fact, you should be doing this from the start. Your experience with the debuggers should grow along side your experience at writing bugs\b\b\b\bcode.

    You really don't want to be just starting to learn how to debug when your programs are 10x larger and the bugs are far more obscure.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Quote Originally Posted by yougene View Post
    >>itCbitC
    No, I haven't figured GDB out yet. It's on my todo list
    Assuming a Windows platform, you can also use Visual Studio for debugger. It's visual and so extremely easy to use.
    And Salem is right - get acquainted with one right now!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Registered User
    Join Date
    Apr 2008
    Posts
    395
    No, I haven't figured GDB out yet. It's on my todo list
    Here's your crash course to locate the faulty part of your code when you get a segmentation violation for instance or anything leading to your program crash:
    1. compile your code with option -g (you're using gcc?) to keep symbols among other things
    2. run gdb with your program as parameter: $ gdb foo
    3. you get the gdb prompt, start your program by entering 'run'
    4. your program crashes, you fall back on the gdb prompt
    5. type 'where', gdb will dump the last instructions, the one at the top is what you're looking for.
    Of course there are many things to learn with gdb but it's all you need to locate a lot of pointer-related problems and save a lot of time*.

    *it does not replace a good program design with adequate builtin checkings, but it remains handy
    Last edited by root4; 01-10-2009 at 04:19 AM.

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    In Visual Studio, all you have to do is run the program in the debugger and it will tell you where the error occured.
    My point is that people needs to stop telling people what debugger to use, or give specific instructions, because which debugger is best is subjective. And if one recommend one, then another will recommend another, like I do.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    a_capitalist_story
    Join Date
    Dec 2007
    Posts
    2,648
    Hey, Elysia...have you ever received a "segmentation fault" in Windows? If not, can you point me to a version of Visual Studio that runs on an OS that reports segmentation faults?

    I know you're a Microsoft partisan, but a little context tells you this person is running this program in the Linux/Unix/BSD world. If this person said they got an Access Violation, I would have pointed them to the Visual Studio debugger.

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Quote Originally Posted by rags_to_riches View Post
    Hey, Elysia...have you ever received a "segmentation fault" in Windows? If not, can you point me to a version of Visual Studio that runs on an OS that reports segmentation faults?
    Since I am the "Windows" type, I don't really pay attention to those "names", I really cannot say I have or not.

    I know you're a Microsoft partisan, but a little context tells you this person is running this program in the Linux/Unix/BSD world. If this person said they got an Access Violation, I would have pointed them to the Visual Studio debugger.
    Are you kidding me? :|
    Linux is a nightmare to me.
    I don't like to guess, so unless an OS is specifically mentioned, I don't really mention a debugger, but merely mention the use of a debugger.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,167
    Just get over it... a segfault is a UNIX/Linux/BSD thing, and GDB is the debugger that has >99% userbase on those systems.

    It's like saying we can't assume a person saying he is using IE 7 is on Windows.

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Segmentation fault is a technical term, and believe or not, it also exists on Windows.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,167
    Yeah, but it's only in popular use on the *nix side. People call it different names on different platforms ("Access Violation" on Windows according to rags_to_riches), but only the *nix people call it "segfault" (it's an affectionate name).

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Segmentation Fault?
    By magda3227 in forum C Programming
    Replies: 10
    Last Post: 07-10-2008, 07:26 AM
  2. Searching and matching strings: segmentation fault
    By Smola in forum C Programming
    Replies: 18
    Last Post: 07-11-2005, 12:25 AM
  3. Binary Search Trees Part III
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-02-2004, 03:00 PM
  4. Segmentation fault...
    By alvifarooq in forum C++ Programming
    Replies: 14
    Last Post: 09-26-2004, 12:53 PM
  5. debugging: sigsegv, segmentation fault???
    By Gonzo in forum C Programming
    Replies: 9
    Last Post: 09-16-2003, 06:56 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21