How to change stack size?
Author
Hi,
Is it possible to change the stack size of a DLL from within the source
code? When using threads you can specify the size of the stack you want
the thread to use, but since my application doesn't use threads I'm
looking for another solution.
Source code I haven't written but which I use creates a structure
containing 4 double arrays of almost 30k. I know this is big but it's
required and I cannot change anything about that.
At the moment I change the stack size via the project solution of the IDE
I'm using and it works for me, but when I ship the .dll and .lib file to
someone else he too has to change the stack size in the project solution
of his IDE. This is something I would like to avoid since it's possible
the required stack size might change in the future and I don't want to
bother the users of the DLL with that.
I'm using plain old (ANSI) C code, so any solution that might be cross platform will help me a lot.
Regards
Why can't you allocate this buffer on the heap? Why does it have to be on the stack? What are you doing with it? I'd find it very hard to believe you can't allocate the memory dynamically with malloc() (since you're using C), which is the "better" way to solve this problem.
The stack is created along with the thread that uses it. Once created, its size is fixed. If your DLL is single-threaded then it will use the creating exe's stack, which your DLL has no control over, as it is created before the DLL is loaded. At least this is the case for Win32.
What I don't understand is how you have successfully altered the size of this stack by changing the DLL's project settings. As far as I understand, this setting only tells the OS what size to default new stacks to. Anyway, here are some of my thoughts.
The default stack size on Windows is 1MB, which can easily accommodate 120k. Are you sure this is a problem you need to fix?
It is the job of the linker to write the exe header entry corresponding to requested stack size. By the looks of things, there is no platform-independent way to specify it. GCC seems to support a #pragma stacksize and Visual C++'s module definition files (.def) also allow for a STACKSIZE specification, but the MSDN corroborates my earlier comments:
So do you have any idea what's going on to cause this confusion?
Admiral
What I don't understand is how you have successfully altered the size of this stack by changing the DLL's project settings. As far as I understand, this setting only tells the OS what size to default new stacks to. Anyway, here are some of my thoughts.
The default stack size on Windows is 1MB, which can easily accommodate 120k. Are you sure this is a problem you need to fix?
It is the job of the linker to write the exe header entry corresponding to requested stack size. By the looks of things, there is no platform-independent way to specify it. GCC seems to support a #pragma stacksize and Visual C++'s module definition files (.def) also allow for a STACKSIZE specification, but the MSDN corroborates my earlier comments:
Quote:Original text from MSDN
This option has no effect on DLLs because the stack size only affects the default stack size for the process.
The reserve argument specifies the total stack allocation in virtual memory. The default stack size is 64K reserve, and 4K committed per thread. The linker rounds up the specified value to the nearest 4 bytes.
The commit argument is subject to interpretation by the operating system. For example, in Windows NT, it specifies the amount of physical memory to allocate at a time.
Committed virtual memory causes space to be reserved in the paging file. The higher the value, the more time the application saves when it needs more stack space. However, this increases the memory requirements and possibly the startup time.
So do you have any idea what's going on to cause this confusion?
Admiral
There's no such thing as a stack size for a dll. Stacks belong to threads. Consult the documentation for your compiler/linker/ide regarding how to change the stack size for an exe.
Otherwise, jpetrie makes a really good point, create your arrays using heap memory.
Otherwise, jpetrie makes a really good point, create your arrays using heap memory.
For Visual Studio:
http://msdn2.microsoft.com/en-us/library/tdkhxaks(VS.80).aspx
I have no idea about gcc. Also, to reiterate, this is not DLL specific, but that's a whole other ball of wax.
http://msdn2.microsoft.com/en-us/library/tdkhxaks(VS.80).aspx
I have no idea about gcc. Also, to reiterate, this is not DLL specific, but that's a whole other ball of wax.
Quote:Original post by tyfius
...but it's required and I cannot change anything about that.
Mind if I ask why? I couldn't imagine one scenario where this would be a requirement so I'm curious.
I suppose you could create a thread from within the DLL but seems like it might be more trouble than it's worth.
If someone is imposing this requirement on you, I'd say create two versions, one using the stack and one using the heap. Show how unworkable their design is, give 'em some good literature on memory allocation and tell him not to come back until he's read it. ;-)
Author
Let me clarify a bit.
There was an existing Linux application which I had to convert more or less into a DLL for MS Windows (and .so file on Linux) so others could use that DLL to create their own implementation of the existing application.
I have one big Visual Studio solution file (and some makefiles for the Linux build) which contains my DLL and a unit test application. This is why most likely I mistakenly accepted that it could be solved by changing the stack size of the DLL while it was actually the unit test executable I modified.
Now, the size of the double array depends on a configuration file. On MS Windows I have to allow every possibility which results in creating a double array of 30k (so 8 * 30k). This array is used 4 times in a structure to accommodate previous and future data. I did a sizeof() and it returned 1.25MB for the array, which is bigger then the 1MB stack size allowed by Visual Studio.
On Linux an application has been build on top of the code using threads and I noticed they have a configuration setting which holds the required stack size which they use when the thread is created.
My best guess is that the error is caused by that structure. I have the following piece of code:
When I started this project I was told to avoid the use of malloc() as much as possible, so that's the reason I did not try this any time sooner, hoping another solution existed.
I'm fairly new to all of this, but I will try to create that structure on the heap tomorrow.
Thanks for the suggestions.
There was an existing Linux application which I had to convert more or less into a DLL for MS Windows (and .so file on Linux) so others could use that DLL to create their own implementation of the existing application.
I have one big Visual Studio solution file (and some makefiles for the Linux build) which contains my DLL and a unit test application. This is why most likely I mistakenly accepted that it could be solved by changing the stack size of the DLL while it was actually the unit test executable I modified.
Now, the size of the double array depends on a configuration file. On MS Windows I have to allow every possibility which results in creating a double array of 30k (so 8 * 30k). This array is used 4 times in a structure to accommodate previous and future data. I did a sizeof() and it returned 1.25MB for the array, which is bigger then the 1MB stack size allowed by Visual Studio.
On Linux an application has been build on top of the code using threads and I noticed they have a configuration setting which holds the required stack size which they use when the thread is created.
My best guess is that the error is caused by that structure. I have the following piece of code:
int doSomething(){ my_stryct_t mstruct;}When I started this project I was told to avoid the use of malloc() as much as possible, so that's the reason I did not try this any time sooner, hoping another solution existed.
I'm fairly new to all of this, but I will try to create that structure on the heap tomorrow.
Thanks for the suggestions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
