Debugging a big double array.

Question

Hello,

I am using a C++ library that provides an object that, for the sake of simplicity, is more or less like this:

class ExampleSO {
    public double* narray;
};

I have an instance of ExampleSO whose narray is about 200. Some other method ExampleSO::method() does a lot of arithmetic functions with this array and assigns it to different array elements:

ExampleSO::method() {
     // a lot of operations
     narray[50] = narray[1] * narray[2] / narray[40];
     // and so on

This code is generated by another program and it uses a bunch of defines to handle the array elements, so the code looks like this:

#define A narray[0]
#define X narray[1]
#define Y narray[2]
// ...
#define Z narray[40]
// ....
#define U narray[50]
// ... more, until narray[199]
ExampleSO::method() {
     // a lot of operations
     U = X * Y / Z;
     // and so on
}

My problem is that eventually some array elements are NaN and I am trying to debug the code to see why. I have already found out some of them, which are mainly caused by divisions by zero, others by exponentiation by very small numbers (small as in between 0 and +/-0.1).

With my little knowledge of gdb magic, I managed to see the array elements by display *(this->narray) @ 200, but this array is very big and therefore, unreadable.

So debugging this piece of code has turned out to be a bundersome task, because the #defines hide me the position of the element, the array is way too big and because so many elements become NaN that I get lost.

My question is: what ideas/suggestions do you have to help me debug this code? Perhaps a conditional breakpoint when the first array element becomes NaN would be useful? How could I do that with such structure?

Thanks!

Answer 1

1. Rewrite it. The structure you describe is horrible beyond description.
2. Write a python script to turn the #defines into gdb variable aliases, so that you can refer to them symbolically.
3. Use array syntax in gdb: p narray[12]
4. Add some debugging helper functions and call them from the debugger: p printMyFavoriteValues(narray)
5. Learn how to enable signalling NaNs. It is different on Windows versus Mac versus Linux.

#ifdef DARWIN
    _mm_setcsr( _MM_MASK_MASK &~
              (_MM_MASK_OVERFLOW|_MM_MASK_INVALID|_MM_MASK_DIV_ZERO) );
#else
    feenableexcept(FE_DIVBYZERO | FE_UNDERFLOW | FE_OVERFLOW | FE_INVALID);
#endif

Answer 2

Regarding the defines you can run the file through the preprocessor and then compile and debug the preprocessed file itself.

The X, Y, Z macros are going to be resolved that way and you see the actual index. How to invoke the preprocessor itself depends on your compiler. For gcc it's the cpp command Documentation.

Regarding finding out when the NaN gets assigned there should be a compiler switch that would make the program throw an exception when that happens.

Answer 3

If you need to debug a large amount of code generated by macro calls and you can't refactor to remove the macros, one option is to temporarily preprocess the file, copy the code generated by the macros and paste it over the macro calls. You'll then be able to compile the already preprocessed code and debug properly. When you're finished just revert the code.