*** stack smashing detected *** How to identify the corresponding line of code

[jodelson]

Hello all!

I am sorry my first post here is a question. I hope to contribute during the posting and replies on this thread.

I am stuck for 1 week in a *** stack smashing detected *** bug in my C program running in a i386 desktop with Ubuntu 7.0.4.
I would have pasted the code here but its approx 2000 lines. It has a dozen of functions and a main program. gdb backtrace reports the error ocurred at the instruction that return from the main program, hence, curiously all the outputs from the program are done successfully but the program does not end normally as it abnormally terimnate with this bug (!!).

I tryed to detect the line in the source code where I could be smashing the stack with valgrind, but I arrived to the conclusion that it can´t help me to debug my current stack smashing error (Reference: Go to the page below on wikipedia, and make a "search in this page" for the "stack smashing"

http://en.wikipedia.org/wiki/Valgrind

I am currently carefully checking each line of code, one by one, trying to find out the buggy statement. Meanwhile I would appreciate if someone could:

1- Point out any tool that may help me to pinpoint where (I mean, in which statement) I am doing this stack smashing?
2- Give me some clues that could help me speeding up the buggy statement identification in the code.

[Banfa]

This sort of error is usually the result of writing to the location pointed to by an uninitialised pointer or writting off the end of an array (buffer overrun).

It is also one of the hardest types of bug to find.

1. Check all your pointers and arrays.

2. If possible try chopping out chunks of code (starting from the end of the program) until the program starts working without error (although obviously the output may not be correct). There is then a good chance that the bug is in the last bit of code you chopped out.

[jodelson]

Problem Solved!
Thank you Banfa, for your valuable contribution.
The buffer overrun occurred because I was passing a parameter longer than 10 characters to the program. This parameter is the name of the file I should read as input. I have defined a string variable of length 10 to store and manipulate this name.

Now I will tell you the story about the debugging as it may help someone with the same problem in the future.

I got an input file with parameters which never leaded to error. I started changing one by one the parameters in the file to make it little by little equal to the one from which I always got the error. At the end both input files were equal and only one leaded to the error. After some minutes of astonishment ... I changed the NAME of the "bad" input file and it run OK. Finally, a quick check in the statements that referenced the name of the input file got me to the overrunning statement!

[Hunderpanzer]

Problem Solved!
The buffer overrun occurred because I was passing a parameter longer than 10 characters to the program. This parameter is the name of the file I should read as input. I have defined a string variable of length 10 to store and manipulate this name.

I'm still new at all of this, but isn't there a new type of string, using #include <string> (no .h) that calculates the amount of space needed, or am I totally on the wrong subject here ?



By the way, Great job both you and Banfa, I'm glad everything worked out well.

[Banfa]

I'm still new at all of this, but isn't there a new type of string, using #include <string> (no .h) that calculates the amount of space needed, or am I totally on the wrong subject here ?

That rather depends on whether the project is written in C or C++.

There is a string type defined in string (no .h) but it is a class and thus only available in C++. There is also the odd occasion (not very often though) when a character array is more desirable than the string class.

[Hunderpanzer]

That rather depends on whether the project is written in C or C++.

There is a string type defined in string (no .h) but it is a class and thus only available in C++. There is also the odd occasion (not very often though) when a character array is more desirable than the string class.

Oh I see, thanks for clearing that up for me.