tags:

views:

513

answers:

7

Hi All,

My PC has 2GB RAM memory. When I form a 3D mesh object having an array of 70.000 items in C# 2008 Express Edition, I get the error message "Stack Overflow exception handled...". If I upgrade RAM memory from 2GB to 4 GB, can I overcome this error message ?

Thanks in advance.

Regards.

Oner YILMAZ

+8  A: 

No. Increasing RAM doesn't increase the stack size.

You're writing code that's causing the stack overflow (perhaps due to recursion) and you'll need to fix that.

Michael Todd
Indeed; infinite recursion is the most likely. +1
Marc Gravell
+12  A: 

Almost certainly not. A stack overflow (rather than an out of memory) means that you've consumed the allocated stack space - but the stack is (relatively speaking) small. The heap is where it is all happening...

Options:

  • fix your infinite recursion bug...
  • move the data into an array/list/some heap-based store (where is it at the moment?)
  • avoid deep recursion
  • avoid oversized structs... have you got some big fat structs that should really be classes? (structs copy themselves if you so much as blink at them)
  • increase the stack space if you are confident that you are only just tipping it over, and it isn't worth a big refactor (I hate this answer) - to do this you would need to spawn your own thread with a bigger stack
Marc Gravell
Note: This response could be read to imply that increasing physical RAM will increase heap size, which is not the case.
Drew Hoskins
Certainly it will, at least on a 64-bit system?
kotlinski
The key point is that it has very little effect on the stack - but (notwithstanding the 2GB/3GB limits of x86) there is still a relationship between physical RAM and available process memory.
Marc Gravell
@kotlinksi: I think @Drew's point is that the heap space can come from the pagefile as well as from actual RAM.
SamB
Note also that the struct/class distinction is a C# thing: in C++ they are the same thing, but with different connotations and default accessibility.
SamB
+2  A: 

Probably not. You should increase the stack size, that's what the error message says

Edit: Or fix the infinite recursion you are likely to have in your code.

erikkallen
+1  A: 

A stack overflow may mean a infinite recursion OR a very deeply nested one.

Incidently, if you have tail recursive methods, the x64 JITter will optimize them and you won't run into stack overflows at all (and your infinite recursion will be...well infinite).

So you could upgrade to a 64bits OS, or fix your code so as not to get into this problem (which is more likely a bug than a too deep nested recursion...)

Yann Schwartz
How come this only works on x64?
SamB
+2  A: 

Physical memory only influences performance of the programs running in the machine but has nothing to do with any memory related problem of a program (on standard operating systems, embed system follow different rules).

First of all, because I've seen this mistake a lot of times, let's talk about he memory model of the operating system.

Almost every user operating system (I'm thinking here on linux, windows, bsd, etc) uses a virtual memory model. Virtual memory model means each program is given full access to a private virtual memory, that is, a representation of memory storage that doesn't have to have the corresponding physical memory.

The size of this virtual memory equals the range that can be addressed by a single machine register. On 32 bits operating systems that means about 4GB. Now, independently of how much actual memory your system have, your program will always think he has 4GB.

Now, those 4GB are, in fact, shared between your program and the space that the operating system reserves for handling data in kernel mode as well as maintaining the structures needed by your program. Being practical you can count with about 2 or 3 GB depending on your configuration (your OS configuration). All of this has nothing to do with the amount of physical memory you have, you can have 256 MB of RAM an still your program will think he has 2GB at his disposal.

When you allocate memory, the system usually doesn't provide exactly the quantity of memory you ask for. Instead it uses pages, which are blocks of reserved memory (for example 4KB) asigned to your process. When you do that, the OS register that "page" as allocated, but this is still in virtual memory. Internally the OS manages which of those pages are kept on physical memory and which of them are in the swap are (in the HDD). That's the reason that increasing you RAM increases your performance (more pages can be in main memory at the same time, and you have to read less from the HDD) but won't help with a stack overflow (or an Out of memory exception by the way).

And that why increasing your RAM won't help.

Finally, about the Stack Overflow exception ... well It's difficult to tell without seeing the actual code, some good answers have already been given.

Mostly stack overflow comes from a infinite recursion, either direct or indirect (A-->B-->C-->A) but in your concrete case I'd say you're just allocating to much data in the stack.

You have a 70000 sized array. I'm guessing that array is full of value types, which are allocated in the stack which, If I recall correctly (and please don't take this as fact) is 1MB in .NET which might be the reason why you're getting your stack overflow.

Jorge Córdoba
A: 

Actually, no. But I have a different reason: Windows XP can only handle up to 2 GB unless you specify a specific boot option in boot.ini. (The /3gb parameter.) At best, Windows XP and Vista will go as far as 3 GB of RAM and that's basically the limit for Windows. See This link for more information about these limits.

Increasing your RAM and fixing your application to go beyond the 2 GB limit might fix your stack overflow, since it might increase the size of your stack. It might also just delay the moment of this stack overflow since, as has been suggested, your code is in a endless recursive loop and will just continue to run until it's out of resources.

If you do use recursion, keep this in mind: anything that you do by using recursion can be rewritten without the use of recursion. There are no exceptions to this rule, although the code won't be easier to read.

Workshop Alex
Actually the /3Gb flag changes the maximum amount of per-process memory that can be allocated. Windows XP and Vista will both happily take 4Gb of RAM but only allow access to approx 3.5Gb of it, with the remaining 500Mb of addressable space being taken for other memory such as video cards, etc.
Jamie Cook
True, but from the application perspective your application will still be limited to 3 GB. Upgrading to 4 GB means less swapping but not more memory for your process itself.
Workshop Alex
A: 

Thanks to all you.

Regards.