[LCP]segmentation fault core dump

[Andrew Weaver]

Good job Mike! 

Mehul, Mike makes a key point here. Your code segmented because you told it
to! That's the thing about computers, they do what they are told but not
always what you want them to do.

Developing a mindset that says "it's not doing what I want, what have I told
it to do instead" is crucial in developing your debugging skills. Both Mike
and I come from an age before interactive debuggers were available. We had
basically two tools, inserting tracing code and post-mortem core dumps
printed on reams of paper.

A long time ago, a friend of mine (hardware techie) explained how she would
set about finding the broken component on a board (in those days it was
still more cost-effective to fix the board rather than throw it away and
replace with a new one). She would read the circuit diagram and then trace
the signals along the circuit with her oscilloscope probes until the signal
did not appear on the other side of a component.

Having found that, she then went more deeply into the component. Simple once
you have seen it and very effective.

In essence, that is the process that Mike has outlined for you.

Good luck and all the best. 

> -----Original Message-----
> From:	Mike & Penny Novack [SMTP:stepbystepfarm at shaysnet.com]
> Sent:	Friday, February 01, 2002 5:13 PM
> To:	linuxcprogramming at lists.linux.org.au
> Subject:	Re: [LCP]segmentation fault core dump
> 
> "If you give a man a fish, you've fed him for a day. If you teach a man
> to fish, you've fed him for a lifetime"
> 
> Mehul,
>     Andrew explained perfectly well what actual mistake was made. I'd
> like to take another tack, to explain how when faced with something like
> this, you figure out what you are looking for.
> 
> 
> >     ret=line_parser(values,str);
> >
> >     for(i=0;i<ret;i++)
> >        printf("%s\n",values[ret]); /*core dump error comes here*/
> >
> 
>     Initially all you know is where you got the seg fault. Well looking
> at that line, you know one of two two things must be true. Either ret is
> an invalid subscript or values[ret] is not the address of a null
> terminated string.
> 
>     Now your function could have returned an invalid subscript.
> Remember, you return -1 for error (you might want to insert explicit
> code to handle that). But you also know that were ret = = -1 you would
> never have executed the body of the for statement since i is never < 0.
> So now you know that (however unexpectedly) values[ret] does NOT point
> to (isn't the address of) a null terminated string.
> 
>     OK, there are just two ways THAT could be. Either it points to a
> string that isn't terminated properly or it doesn't point to a string at
> all. How to progress further depends upon whether you use debugging
> tools or the old fashioned way. Quick and easy would be to insert (ahead
> of the printf) an assertion that values[ret] != NULL. If the assertion
> fails you know you (still) have a NULL pointer there. If you get the seg
> fault again, you know the string wasn't properly terminated.  In your
> case, the assertion will fail, so now you are looking to figure out how
> that could have happened.
> 
>     Since this turned out to be as fundamental as the initial function
> definition, I'm going to stop the analysis and address Andrew's
> suggestion. It's oh too easy to get lost with levels of pointing, and
> even the most experienced of us can type the wrong number of asterisks.
> Worse, such mistakes are very difficult to see. Essentially Andrew is
> suggesting that judgicious use of "temporary" variables may make your
> code easier to read and much easier to debug. In fact, that's a pretty
> big function. While it might be necessary or desirable for reasons of
> efficiency to keep function call overhead to a minimum, during
> "development" debugging is easier if alll functions perform more limited
> processing --- you can always "unwind" some of the function calls after
> initial testing.
> 
> Mike
> 
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List