Problem only when running in debugger

Question

I have a project where I can make a Debug build and start the program from the command line, but when I use the VS2008 debugger to run the program (it's an exe) it crashes early on saying it couldn't get a few hundred MB of memory allocated.

Why would it be asking for so much more memory when running from the debugger?  I am assuming it asks for less memory, and gets it, when just running from the command line, since the command line run doesn't crash.

If anyone can point me in the right direction or where to begin, I'd appreciate it.

Answer 1

Hi msnhelpsme,

it would be helpful if you posted the exact error message you have.

Answer 2

I don't really have an error message except for a custom one telling me where the problem occurred.  But what's happening is a call to VirtualAlloc is failing when I ask for like 400+MB but succeeding when I ask for like 200MB.  It only asks for 400+MB when I run it in the debugger.

So why would my program be asking for almost twice as much memory when ran through the debugger?

Answer 3

It is difficult to guess, you do not provide any code or error message.

Looks you have memory fragmentation.

VirtualAlloc fails if there is no big enough contiguous free or reserved address range.

Answer 4

I'm not sure what else to post about it.  It's a call to VirtualAlloc.  The details shouldn't matter, since the call works when I don't use the debugger.  If the only difference is the size of the request, that's what I am curious about.  Why does using a debugger to execute the exact same code cause a significantly larger request?

Answer 5

If you don't know what the problem is, it is illogical to make assumptions about what is significant or not.

You have code that generates a custom error message.  Post it and the code that triggers it.

Answer 6

Ok, this call returns NULL:

VirtualAlloc(NULL, 482803712, 8192, PAGE_READWRITE);

Any ideas?

Answer 7

On 8/6/2012 6:43 PM, msnhelpsme wrote:

Ok, this call returns NULL:

VirtualAlloc(NULL, 482803712, 8192, PAGE_READWRITE);

Any ideas?

Apparently, your process doesn't have a contiguous chunk of address space 460MB large.

---

Igor Tandetnik

Answer 8

On 8/6/2012 6:43 PM, msnhelpsme wrote:

Ok, this call returns NULL:

VirtualAlloc(NULL, 482803712, 8192, PAGE_READWRITE);

Any ideas?

Apparently, your process doesn't have a contiguous chunk of address space 460MB large.

---

Igor Tandetnik

Ok, but is there a reason why this asks for 460MB when running in the debugger but less when just executed from the command line?  I assume it probably asks for significantly less when on the command line - and the command line invocation always works.

Answer 9

On 8/6/2012 7:03 PM, msnhelpsme wrote:

On 8/6/2012 6:43 PM, msnhelpsme wrote:

Ok, this call returns NULL:

VirtualAlloc(NULL, 482803712, 8192, PAGE_READWRITE);

Any ideas?

Apparently, your process doesn't have a contiguous chunk of address space 460MB large.

Ok, but is there a reason why this asks for 460MB when running in the debugger but less when just executed from the command line?

The line of code you've shown certainly asks for 482803712 bytes (that is, 460MB), regardless of how it was executed. I'm not sure I understand the question.

I assume it probably asks for significantly less when on the command line - and the command line invocation always works.

If this line fails under debugger but works without, this is most likely because the debugger itself loads some DLLs and/or allocates some memory in the process' address space, thus reducing the amount available for the process' own allocations. No debugger means less overhead and more address space available for the process.

By trying to allocate so much memory in a 32-bit application, you are pushing very close to the limits of what's possible. Small environmental changes (such as the presence or absence of the debugger) may then easily push you over these limits.

---

Igor Tandetnik

Answer 10

The line of code you've shown certainly asks for 482803712 bytes (that is, 460MB), regardless of how it was executed. I'm not sure I understand the question.

If this line fails under debugger but works without, this is most likely because the debugger itself loads some DLLs and/or allocates some memory in the process' address space, thus reducing the amount available for the process' own allocations. No debugger means less overhead and more address space available for the process.

By trying to allocate so much memory in a 32-bit application, you are pushing very close to the limits of what's possible. Small environmental changes (such as the presence or absence of the debugger) may then easily push you over these limits.

---

Igor Tandetnik

Sorry, my code posting was a bit misleading.  The value 482803712 is stored in a variable.  I just didn't use the variable's name when posting the code.  So in reality, things are like this:

//With debugger, myVar =  482803712
VirtualAlloc(NULL, myVar, 8192, PAGE_READWRITE);

Now maybe myVar is the same with and without the debugger.  That would make some sense.  But this is running on a 64-bit Windows 7 machine, so 482803712 should not be a problem, right?

Answer 11

On 8/6/2012 7:34 PM, msnhelpsme wrote:

Sorry, my code posting was a bit misleading. The value 482803712 is stored in a variable. I just didn't use the variable's name when posting the code. So in reality, things are like this:

//With debugger, myVar =    482803712
VirtualAlloc(NULL, myVar, 8192, PAGE_READWRITE);

Now maybe myVar is the same with and without the debugger.

Why guess? Print it, find out for sure.

But this is running on a 64-bit Windows 7 machine, so 482803712 should not be a problem, right?

It doesn't matter that the OS is 64-bit, as long as your application is a 32-bit process. You are very likely not running out of physical memory, but out of address space. A 32-bit process has 2GB of address space available to it, which has to hold the actual code of the EXE and all DLLs it loads, as well as any memory allocations.

---

Igor Tandetnik

Answer 12

But this is running on a 64-bit Windows 7 machine, so 482803712 should not be a problem, right?

Make sure you link your program as "large address aware",
then it (a 32-bit process) will have access to 4GB when
executed under Win64. Otherwise it will only have 2GB to
work with.

- Wayne

Answer 13

Ok, more discoveries.  It might not be the debugger after all.  There are 3 ways to start the program:

1. Debugger - gives me memory error
2. Start as service via command line command - no problems
3. Type name of executable from command line - gives me memory error

Since starting as a service from command line always worked, I assumed it was the debugger.  But I may be running out of address space.  I will try linking like Wayne suggests, but until then, does anyone know what the difference is between starting as a service and just typing name of exe?

Answer 14

But this is running on a 64-bit Windows 7 machine, so 482803712 should not be a problem, right?

Make sure you link your program as "large address aware",
then it (a 32-bit process) will have access to 4GB when
executed under Win64. Otherwise it will only have 2GB to
work with.

- Wayne

The largeaddressaware option is present when building.  So it would seem that the only issue could be physical limitations of the machine itself then, right?

Answer 15

The fact that your program is requiring 460 MB of heap memory might be a sign of a poorly thought out design. Can you justify the need for this much memory as a contiguous block? Also, have you considered creating an x64 application?