C++: release/debug & minor code changes give unexpected results

Discussion in 'Mac Programming' started by adammcd, Mar 5, 2010.

  1. adammcd macrumors member

    Nov 15, 2007
    Computer: MacBook Aluminum Unibody (2 Ghz Intel Core 2 Duo), Running 10.6.2

    Software: Xcode 3.2, trying 10.5 SDK, 10.6 SDK, release and debug modes. Also (separately) Qt Creator 1.3.1 (based on Qt 4.6.1 32 bit).

    I am writing a simple C++ command-line utility program that counts paths through a 3D lattice of points (starting with the 2x2x2 case, but written to work for NxNxN). My program seems pretty simplistic (it only defines integers & integer arrays and does stuff with them - no strings or floats or file reading/writing). I am running into various (likely related) problems. OF these, problems (2) and (3) bother me the most...

    (Problem 1) In general, I get significantly different results if I compile & run my program in debug vs. release mode. I have read an overview of the differences between debug & release, but I am too much of a novice to figure out what is going on.

    (Problem 2) Instead of going through the debugger, I sometimes insert output such as {cerr << "The value of N is " << N << endl;}. I get this strange happening: adding such a line of output will sometimes significantly affect seemingly unrelated results when running the program. That is, I can run my program and get "Answer = 15", but with a line of output in a benevolent spot can change this to "Answer = 13" after I rebuild & run again. This is mind boggling to me.

    (Problem 3) In my program, I define an integer array check[N+3][N+3][N+3] (which is check[5][5][5] for now, since N=2). The check array is initialized to hold all 0's, and entries are changed to and from 0 and 1 along the way (with a while loop). I get an unexpected change of variable at one point, and I have no idea how it is happening - a snippet of the code and the terminal output from running the program is given below...

    Here is the code snippet:
    if(X == start1 && Y == start2 && Z == start3)
        check[start1][start2][start3] = 0;
        cout << "output1: check[1][1][1] = " << check[1][1][1] << endl;
    // the code here does not redefine or call the check array
    // the check array is not mentioned what-so-ever
    cout << "output2: check[1][1][1] = " << check[1][1][1] << endl;
    Here is the corresponding output in the terminal:
    output1: check[1][1][1] = 0
    output2: check[1][1][1] = 1
    I have stepped through the part of the program in the debugger and check[1][1][1] mysteriously changes from 0 to 1.

    Any help or comments would be appreciated -- thanks.
  2. Detrius macrumors 68000

    Sep 10, 2008
    Asheville, NC
    You don't specify how you're declaring your array. So far as I'm aware, C++ doesn't allow dynamically sized arrays on the stack. I believe C has added this capability in the not-too-distant past, but C++ has not.

    Next, you don't really show us any of your code, so we can't tell you what's really going on. OBVIOUSLY, you have a bug. It can be really bad if your code behaves differently under debug vs. release. There's a known bug with file streams in debug mode in the latest version of Xcode, but I don't know if that's relevant to you since there's no code shown.

    Without seeing any of your code, we can't really tell you if you are improperly accessing your own array or if there's a stack-smashing or heap-smashing bug elsewhere. We need more information. If you can post a minimal case that exhibits the bug, we can work with that.
  3. gnasher729 macrumors P6


    Nov 25, 2005
    Differences between debug and release versions usually mean that you are using an uninitialised variable somewhere, which would have a different random value depending on the version, or you are writing past the end of some array, which would modify different variables depending on the version.

    For example, if you have

    int i, a [10];
    for (i = 0; i <= 10; ++i) a [i] = 0;
    the last assignment will set some memory somewhere to 0 where it shouldn't, and the effect of that can be hugely different between debug and release.

    I recommend you start stepping through your code to see where it does something you don't expect. But first turn all compiler warnings on; they often give you a hint when you made some stupid mistake.
  4. adammcd thread starter macrumors member

    Nov 15, 2007
    gnasher, you were right. There was array that was length N^2 should have been length (N+1)^2. I'm pretty rusty with my C++ knowledge ... I forgot (or never realized) that writing a value to a uninitialized array could actually affect existing (legitimate) values in an unrelated array. I guess this makes sense - it doesn't have a spot to write to, so it finds somewhere else to write to.

    I'm lucky my program was relatively small; I can't imagine trying to chase down such an error in a much larger C++ program.

    Sorry I was so vague, but your comments did help ... thanks!

Share This Page