How to check the peak stack size of all thread in a process.

Started by
3 comments, last by laiyierjiangsu 6 years, 9 months ago

Hi, guys!

             My prograss crashs with a stackoverflow exception in some pcs.  I changed the stacksize of thread from default(1M) to (2M) for fixing this problem. But  I have got confused with some doubts.

1、Why this exception happens in some pcs not all?  I think the logic is the same ,so the stack used must be identified too.

2、Why the default stack size is 1M? Just for saving the memory of process or have some other reasons?

3、Can there any tools or methods for me to find the logic where using so much stack?

Stay hungry, stay foolish!

Advertisement

1 - Normal stack size is around 4mb if I recall correctly, but that doesn't mean it can't be deviated from, hence you sometimes get a crash (though someone more knowledgeable on this may know of other reasons). Also if you're not sure if the stack is the same, there lies an explanation as well, you should compare the actual data on the stack, because this may be a cause as well. If it's not the exact same playthrough, this is more likely the reason I'd say.

2. 1 mb is kind of a safe bet to start out with and afaik will be the minimum supported by (modern) CPU's. 

3 - Just take a look at the stack. You can attach a debugger like visual studio or just run it in that environment in the first place (after all, you're hitting it pretty consistently). Once it hits any exception, it should break and you can view the current stack. Such high stack usage is quite worrisome. It can indicate a high amount of recursion (i.e. a function calling itself), with the stop condition perhaps being incorrect (pretty common), large stack allocations such as by large arrays or simply huge objects (but I'd consider this less likely) and even less likely, you can have a lot of indirection, but I'd consider that it's very unlikely you will hit stack limit by just regular function calls, especially in release.

Regardless, having to increase the default stack size is something I'd definitely not consider a decent solution at all, so you should definitely look into the cause

The default stack size on Windows is 1MB.

1. The stack size doesn't change on different computers. Maybe some people don't use the feature that consumes lots of stack space, or its stack consumption depends on the input data? 64-bit code will also consume more stack space than 32-bit.

2. Windows supports any stack size that will fit in RAM. You can change it in the linker settings, or as a parameter when creating a thread. I guess 1MB is a reasonable trade off between how much space the program gets to use, and the memory that's consumed by creating a thread, but if you have different requirements you can change it. Also if your stack is too big buggy recursive functions could take a long time before they fail with a stack overflow.

3. When it's crashed in the debugger add the esp (or rsp for x64) register to the watch window. That's the stack pointer, and you can watch it change as you move up and down the call stack in the debugger. Looking at how much it changes by will tell you how much stack is used. Alternatively just look at the size of the local variables in each function on the call stack until you find the big ones - you can use sizeof(variableName) in the watch window to see how big something is.

Thanks ,you guys give me some inspire, I will try it.

13 hours ago, Adam_42 said:

The default stack size on Windows is 1MB.

1. The stack size doesn't change on different computers. Maybe some people don't use the feature that consumes lots of stack space, or its stack consumption depends on the input data? 64-bit code will also consume more stack space than 32-bit.

2. Windows supports any stack size that will fit in RAM. You can change it in the linker settings, or as a parameter when creating a thread. I guess 1MB is a reasonable trade off between how much space the program gets to use, and the memory that's consumed by creating a thread, but if you have different requirements you can change it. Also if your stack is too big buggy recursive functions could take a long time before they fail with a stack overflow.

3. When it's crashed in the debugger add the esp (or rsp for x64) register to the watch window. That's the stack pointer, and you can watch it change as you move up and down the call stack in the debugger. Looking at how much it changes by will tell you how much stack is used. Alternatively just look at the size of the local variables in each function on the call stack until you find the big ones - you can use sizeof(variableName) in the watch window to see how big something is.

 

On 2017/6/26 at 5:11 PM, AthosVG said:

1 - Normal stack size is around 4mb if I recall correctly, but that doesn't mean it can't be deviated from, hence you sometimes get a crash (though someone more knowledgeable on this may know of other reasons). Also if you're not sure if the stack is the same, there lies an explanation as well, you should compare the actual data on the stack, because this may be a cause as well. If it's not the exact same playthrough, this is more likely the reason I'd say.

2. 1 mb is kind of a safe bet to start out with and afaik will be the minimum supported by (modern) CPU's. 

3 - Just take a look at the stack. You can attach a debugger like visual studio or just run it in that environment in the first place (after all, you're hitting it pretty consistently). Once it hits any exception, it should break and you can view the current stack. Such high stack usage is quite worrisome. It can indicate a high amount of recursion (i.e. a function calling itself), with the stop condition perhaps being incorrect (pretty common), large stack allocations such as by large arrays or simply huge objects (but I'd consider this less likely) and even less likely, you can have a lot of indirection, but I'd consider that it's very unlikely you will hit stack limit by just regular function calls, especially in release.

Regardless, having to increase the default stack size is something I'd definitely not consider a decent solution at all, so you should definitely look into the cause

 

Just now, laiyierjiangsu said:

Thanks ,you guys give me some inspire, I will try it.

 

Stay hungry, stay foolish!

This topic is closed to new replies.

Advertisement