1

When debugging my project in visual studio (2010) I get the message "no source available" once I step into one of my files. The file is now just a test file with one function:

void foo()
{
    float testbuf[200000] = {0};
}

If i allocate a smaller buffer the debugger enters the file normally. In my debugging view my "call stack location" is empty and there is "no disassembly available".

It looks to me like there is a maximum amount of data that the visual studio debugger can handle or something in this direction.

Could someone tell me if this is the problem and how I can fix it. Maybe some Visual Studio settings can help me out?

mstrdenz188
  • 323
  • 2
  • 3
  • 10
  • 1
    First of all, why do you use VS2010 which is almost 6 years old? What are `DEFINE_1024` and `DEFINE_6`? Do you run in debug mode (optimizations disabled, debug info enabled)? Can you produce a [MCVE](http://stackoverflow.com/help/mcve)? – Ivan Aksamentov - Drop Nov 18 '15 at 11:34
  • You'll have to give context, it isn't even clear if you blew the stack with these arrays or the machine is just mad at you for using sizeof(double) in a float[] declaration. The call stack when it bombs is crucial too. – Hans Passant Nov 18 '15 at 11:47
  • I don't know what the problem is, but having an array of `float` whose size is calculated by the number of bytes in a `double` seems very strange. (It would be just as strange if the size was calculated by the number of bytes in a `float`, of course.) – ymett Nov 18 '15 at 11:51
  • I simplified to code example to a bare minimum, so I hope its MCVE now. I also think it almost can't be a code/syntax problem at this point. – mstrdenz188 Nov 18 '15 at 13:44
  • Is it a release build where the method has been optimized away because it is not doing anything? – Thomas Weller Nov 19 '15 at 19:29
  • No it's a debug build. In a release build nothing seems to be wrong. Also the problem is only the actual debugging of the code. – mstrdenz188 Nov 23 '15 at 07:27

1 Answers1

0

I have found a way to avoid the problem. If I create the buffer "dynamically" by just malloc-ing the same big buffer then Visual Studio has no problem debugging my source file. Code example:

void foo()
{
    float *testbuf;
    testbuf = (float*) malloc(200000*sizeof(float)); // "dynamic" malloc
    memset(testbuf, 0, 200000*sizeof(float)); // Make sure buffer is empty.
    // Code (irrelevant to example)
    free(testbuf);
}

So this does not answer the question what the maximum capacity of stack memory is for the visual studio debugger but it does provide a workaround to the problem.

I hope this will help someone.

mstrdenz188
  • 323
  • 2
  • 3
  • 10