Home/ Questions/Q 7659499
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T13:20:27+00:00

I’v run into an odd problem, my process cannot allocate more than what seems

  • 0

I’v run into an odd problem, my process cannot allocate more than what seems to be slightly below 1 GiB. Windows Task Manager “Mem Usage” column shows values close to 1 GiB when my software gives a bad_alloc exception. Yes, i’v checked that the value passed to memory allocation is sensible. ( no race condition / corruption exists that would make this fail ). Yes, I need all this memory and there is no way around it. ( It’s a buffer for images, which cannot be compressed any further )

I’m not trying to allocate the whole 1 GiB memory in one go, there a few allocations around 300 MiB each. Would this cause problems? ( I’ll try to see if making more smaller allocations works any better ). Is there some compiler switch or something else that I must set in order to get past 1 GiB? I’ve seen others complaining about the 2 GiB limit, which would be fine for me.. I just need little bit more :). I’m using VS 2005 with SP1 and i’m running it on a 32 bit XP and it’s in C++.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    On a 32-bit OS, a process has a 4GB address space in total.

    On Windows, half of this is off-limits, so your process has 2GB.

    This is 2GB of contiguous memory. But it gets fragmented. Your executable is loaded in at one address, each DLL is loaded at another address, then there’s the stack, and heap allocations and so on. So while your process probably has enough free address space, there are no contiguous blocks large enough to fulfill your requests for memory. So making smaller allocations will probably solve it.

    If your application is compiled with the LARGEADDRESSAWARE flag, it will be allowed to use as much of the remaining 2GB as Windows can spare. (And the value of that depends on your platform and environment.

    • for 32-bit code running on a 64-bit OS, you’ll get a full 4-GB address space
    • for 32-bit code running on a 32-bit OS without the /3GB boot switch, the flag means nothing at all
    • for 32-bit code running on a 32-bit OS with the /3GB boot switch, you’ll get 3GB of address space.

    So really, setting the flag is always a good idea if your application can handle it (it’s basically a capability flag. It tells Windows that we can handle more memory, so if Windows can too, it should just go ahead and give us as large an address space as possible), but you probably can’t rely on it having an effect. Unless you’re on a 64-bit OS, it’s unlikely to buy you much. (The /3GB boot switch is necessary, and it has been known to cause problems with drivers, especially video drivers)

    • 0