[feature not a bug?] dcc --valgrind reports uninitialised variable errors when accessing an array that was created-inside-and-returned-from a function

[andrewjbennett]

Hard to describe, so example code:

int *copyNumbers(int cards[]) {
    int copy[N_CARDS];

    // have some sort of loop to copy all of the values from the `cards` array that's passed in
    // into the `copy` array that we've just created. 

    return copy;
}

Trying to run the following code:

int *copied = copyNumbers(cards);
int first_number = copied[0];

will give an uninitialised variable access error on the second line.

---

Example screenshot from student who ran into this:

While yes, it is technically correct that the array they're trying to access is uninitialised memory (because the function has returned so the array has gone out of scope and ??? undefined behaviour ???), I would have expected an error message that gave some information about what had happened (e.g. ASAN's stack-use-after-return -- which yeah I don't expect valgrind to be able to give ASAN error messages, so maybe this is more specific to the situation when you're running both dcc --valgrind and "normal" dcc?).

[comp1511]

The student code didn't initialize array element[0] (as well as use after return)

[andrewjbennett]

Yes they did:

int* getFactors(int num) {

    int factors[50];
    int count=1;
    int localNum = num;

    for(int x=2; x <= localNum-1; x++) {
        if(num % x == 0) {
            factors[count] = x;
            count++;
        }
    }
    factors[0] = count;

    int *factorPointer = factors;
    return factorPointer;

}

Unless I've somehow totally misunderstood:

count variable is created with value 1
factors[0] is set to count (which will be either 1 or a number higher than 1)
*factorPointer = factors (so factorPointer[0] is factors[0] is initialised)
factorPointer is returned

Part of the problem is that the variables seem to have totally reasonable values in them, according to the dcc helpful python/gdb output -- within the function, factors[0] would have actually been 3, and that's what it seems to still have, so it's not at all obvious what the problem is (unless you've seen it before, of course).

[comp1511]

OK I understand now - valgrind notices ref below stack pointer. I've added a code to intercept this and explain in 7e5cfd4