I have a buggy program that pushes a variable onto stack and may use it without initialization.

I take the same binary and run it on different Linux boxes. Those boxes have different CPUs (i5, i7), but other than that they run the same Fedora distro.

One one box, I can easily catch the problem because the variable has random data.

On another box, however, the stack variables are always initialized to 0 (even though they should not be).

I am trying to pin down the cause of this different behavior. Where should I look at? What can possibly cause this? Are there any kernel features that can affect this?

  • The cause is the bug in the program. – David Schwartz Oct 9 '13 at 0:47
  • The CPU's should have nothing to do with it. However I can imaging different outcomes when using initilised memory on boxes with different amounts of RAM (clean, never used before vs containing old data) or with different libraries (e.g. one callocing the space before giving the program access). – Hennes Nov 23 '16 at 13:42

There is no "should" or "should not" for uninitialized data. It can be whatever it darn well pleases. All zeros is a possibility - so is all ones, and so is random garbage. Indeed, all zeros is one perfectly acceptable form of random garbage. Rather than concerning yourself with what the uninitialized data is on different boxes, initialize it, and then (and only then) you can know what it "should be."

  • Thank you Captain. The question is why random is not random in certain environments. SELinux extensions, some stack protector features in glibc, etc? – user49531 Oct 9 '13 at 1:36

In C, the initialization of variables depends on the level of optimization when the program was compiled.

Optimization level 3 won't initialized any variable in the stack.

gcc -O3 program.c -o program

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.