help on *** stack smashing detected ***

This is a discussion on help on *** stack smashing detected *** within the C Programming forums, part of the General Programming Boards category; Hello all! I am sorry my first post here is a question. I hope to contribute with some info given ...

  1. #1
    Registered User
    Join Date
    Aug 2007
    Posts
    5

    Question help on *** stack smashing detected ***

    Hello all!

    I am sorry my first post here is a question. I hope to contribute with some info given in my question posing.

    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 after some additional research 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 my code.
    Last edited by jodelson; 08-16-2007 at 11:01 AM.

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    It seems the most likely scenario is that a local array in your main() function has been overrun, given that the program has basically done it's job and is failing right at the last moment.
    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.

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Is this built with optimisation? In that case, it's very likely that it could be ANY line of code in your application - gcc can easily inline everything in a 2000 line .c file into a single function (in this case main).

    You may want to try compiling with less/no optimization and see if that helps.

    I would add assert() or some other checking mechanism to every place where it's possible that some index is getting out of range.

    You could of course also randomly increase the size of your arrays (one at a time) to see if that helps - but that's akin to the mechanics swapping any and all parts of an engine to see if it fixes the problem, rather than actually identifying something wrong first, then fixing the actual problem.

    --
    Mats

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,236
    Quote Originally Posted by jodelson View Post
    Valgrind can't detect stack corruption. Fortunately, almost all stack-related problems are caused by buffer overflows. Carefully look at all local array variables. Try to find the code which is overrunning one of them.

    Because of the way local variables are stored, local variables in higher frames will also be corrupted during a buffer overflow. This makes it possible to use a trick to detect where the overflow occurs:

    Code:
    int main()
    {
        int overflow = 0x55AACCFF;
    
        /* Your code */
    }
    Then run your program in gdb. Before starting it, add a watchpoint on the overflow variable with the command: "watch overflow". Then let it run. Hopefully, when the overflow occurs, it will change the value of the overflow variable and your program will break. Then you should be able to see what happened.

    The problem with allowing it to crash is that it crashes AFTER the corruption has happened, so you don't see it happening.

  5. #5
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    If you're using gets(), don't. Use fgets() instead. It could be the reason behind a buffer overflow.

  6. #6
    Registered User
    Join Date
    Aug 2007
    Posts
    5

    Wink

    Quote Originally Posted by matsp View Post
    Is this built with optimisation? In that case, it's very likely that it could be ANY line of code in your application - gcc can easily inline everything in a 2000 line .c file into a single function (in this case main).

    You may want to try compiling with less/no optimization and see if that helps.

    I would add assert() or some other checking mechanism to every place where it's possible that some index is getting out of range.

    You could of course also randomly increase the size of your arrays (one at a time) to see if that helps - but that's akin to the mechanics swapping any and all parts of an engine to see if it fixes the problem, rather than actually identifying something wrong first, then fixing the actual problem.

    --
    Mats
    Unfortunately, I had already compiled with "-ggdb -O0". Anyway I likde your clue of using assert. All indexes are declared together in the very beginning of the program so I will code an assert statement for each index and try to trap the over run with assert().

  7. #7
    Registered User
    Join Date
    Aug 2007
    Posts
    5

    Wink

    Quote Originally Posted by MacGyver View Post
    If you're using gets(), don't. Use fgets() instead. It could be the reason behind a buffer overflow.
    Thank you. I reviewed my code doing a find "gets" and all input are done with fgets()

  8. #8
    Registered User
    Join Date
    Aug 2007
    Posts
    5

    Unhappy

    Quote Originally Posted by brewbuck View Post
    Valgrind can't detect stack corruption. Fortunately, almost all stack-related problems are caused by buffer overflows. Carefully look at all local array variables. Try to find the code which is overrunning one of them.

    Because of the way local variables are stored, local variables in higher frames will also be corrupted during a buffer overflow. This makes it possible to use a trick to detect where the overflow occurs:

    Code:
    int main()
    {
        int overflow = 0x55AACCFF;
    
        /* Your code */
    }
    Then run your program in gdb. Before starting it, add a watchpoint on the overflow variable with the command: "watch overflow". Then let it run. Hopefully, when the overflow occurs, it will change the value of the overflow variable and your program will break. Then you should be able to see what happened.

    The problem with allowing it to crash is that it crashes AFTER the corruption has happened, so you don't see it happening.
    I tried your trick as described above but the variable named overflow seems not to change before the program end as I get the same result as before. I expected the program to stop when the overflow variable was changed.

  9. #9
    Registered User
    Join Date
    Aug 2007
    Posts
    5
    Problem Solved!
    Thank you all guys for all the valuable contributions.
    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!
    Last edited by jodelson; 08-16-2007 at 06:27 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. *** stack smashing detected ***
    By chakra in forum C Programming
    Replies: 2
    Last Post: 06-09-2009, 09:12 PM
  2. *** stack smashing detected ***
    By Martin_HS in forum C Programming
    Replies: 9
    Last Post: 05-29-2009, 04:01 AM
  3. stack and pointer problem
    By ramaadhitia in forum C Programming
    Replies: 2
    Last Post: 09-11-2006, 11:41 PM
  4. Question about a stack using array of pointers
    By Ricochet in forum C++ Programming
    Replies: 6
    Last Post: 11-17-2003, 09:12 PM
  5. error trying to compile stack program
    By KristTlove in forum C++ Programming
    Replies: 2
    Last Post: 11-03-2003, 05:27 PM

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