hi all,

relatively new to c++.

may i know how do i solve

*** stack smashing detected ***
error?

i am actually runnning some open source software
however when i upgrade to ubuntu 9.04, it seems to give me this error when i run the program.

i did some research online,
below is a site which i read about stack smashing,
http://www.de-brauwer.be/wiki/wikka.php?wakka=StackSmash
this is the first time i encouter, it had been running smooothly on ubuntu 8.10 and xubuntu 8.10..

i tried increasing the buffer size used in the cpp files it still did not work.
i cant test the example given from the site above as the cpp files are being invoked by a perl script.

please advise.

This message is generated when the program is compiled with the "stack-protector" flag enabled and the program stack gets corrupted (probably by some kind of memory access violation). With the Ubuntu 9.04 distribution, it enabled by default. With other distributions that I have, it is not enabled by default. The Makefile of the software distribution may or may not have compiled explicitly with a flag "-fstack-protector". Without the "stack-protector" flag, a memory access violation might generate a message like "segmentation fault."


The usual cause is writing outside the bounds of an array. Note that there may be other bugs that manifest themselves by generating this error message, but my experience is that this is the most common cause. See Footnote.

Anyhow...

The result of writing beyond the bounds of an array is "undefined behavior."

Depending on other things in the program, "undefined behavior" may cause no apparent problems.

It may cause an immediate program crash.

The program might have overwritten other variables and the result would be a crash sometime later in the program when the corrupted variable's value was used somehow.

Sometimes the program might actually run with no apparent problems, but crash with this message when the program exits.

Bottom line: The behavior of a program with undefined behavior is, well, undefined.


Maybe the program us writing to an array using a negative array index. Maybe the program is using the value of an uninitialized variable value as an index to write to the array. Some compiler versions "helpfully" load all variables with zero values before starting up while some do not. Maybe the uninitialized variable value happens to be some verrrrrry large number, so that modest (or even immodest) increases in array sizes won't keep it from happening. Even if you could "fix" the problem by some band-aid like blindly increasing sizes of arrays, the program would still have a bug if it uses an uninitialized variable value as an array index.

Bottom line, rev 2.0: The program has a bug. If you can't analyze it, then maybe you can contact the program's author with a bug report. (If you are using some unmodified open source program that is available on the internet, you could even tell us what it is and what you are doing with it.)

Tell the author:

1. Exactly what version compiler you are using. Tell whether there were any compiler messages when you compiled the program. List the messages.
   
   
2. Exactly how you are using the program. If there are user input lines, tell exactly what you fed the program. If there are user input files, tell exactly what was in the files (post the files).
   
   
3. Whether the problem is repeatable. Does exactly the same thing happen every time you run the program?
   
   
4. Anything else that you can think of that would allow someone to reproduce the exact conditions under which you are running the program.

Regards,

Dave

Footnote: In general, because of (among other things) the possibility of undefined behavior, you can't "prove" a program is valid by testing alone.

That is why it is very important to tell us exactly what the program was doing at the time of the crash. There are tools (valgrind, for example) that sometimes can give some information about invalid use of allocated memory. Or, maybe, not.

Also using a debugger (gdb for example) can sometimes help isolate the problem area to let you know where to look for the bug. Or, maybe, not.