Stack size question
-
Is there a way to tell how much stack space I need? I have a multi threaded app that creates worker threads. There are very few variables in the main app. I am getting strange memory errors. Is it possible the default stack size for the threads (= stack size of main) is too small? How can I find out how big it is? How can I find out how big it needs to be? I get no explicit errors, just lots of strange things. Thanks for the help, Bill
-
Is there a way to tell how much stack space I need? I have a multi threaded app that creates worker threads. There are very few variables in the main app. I am getting strange memory errors. Is it possible the default stack size for the threads (= stack size of main) is too small? How can I find out how big it is? How can I find out how big it needs to be? I get no explicit errors, just lots of strange things. Thanks for the help, Bill
I'd say the default stack size is much more than necessary for the needs of normal apps. The only way a normal app can run out of stack size is because of some bug that causes an infinite chain of recursive calls to functions. But then again, you have no reason to suspect this is happening. My suggestion is that you try to look for another reason to your strange errors. If you describe the problem with more detail we could try to help you more than this. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
I'd say the default stack size is much more than necessary for the needs of normal apps. The only way a normal app can run out of stack size is because of some bug that causes an infinite chain of recursive calls to functions. But then again, you have no reason to suspect this is happening. My suggestion is that you try to look for another reason to your strange errors. If you describe the problem with more detail we could try to help you more than this. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
My concern was that the actual stack requirements of a worker thread greatly exceeds that of the parent thread. The parent merely dispatches jobs to the workers. I thought maybe I didn't have enough stack space in the worker threads. The specific problem (at the moment) is with using Crystal Reports. I have a wrapper class (CCrystalReports) that uses the CR API (not the com object). The wrapper has been used successfully in several single threaded apps. I've tried this two different ways with different, but always disappointing :(( , results. 1. Make CCrystalReports a member of the Worker thread class. This mode of operation had no memory problems as far as I can tell. Crystal Reports, however, failed to open the report file in this configuration. 2. Make CCrystalReports a dynamic in a method called by the worker thread. (So it is automatically destroyed at the right time. This runs for awhile, then blows when trying to return from the method. The actual blow up occurs in yet another program. The app I have been discussing supports a COM interface. Another program uses this interface to submit requests to the app, which then dispatches them to worker threads. The blowup comes in the Invoke call it returns the following error: (8007000e) Not enough storage is available to complete this operation. Any advice would be appreciated. This project has gone on too long! Thanks for the help, Bill
-
My concern was that the actual stack requirements of a worker thread greatly exceeds that of the parent thread. The parent merely dispatches jobs to the workers. I thought maybe I didn't have enough stack space in the worker threads. The specific problem (at the moment) is with using Crystal Reports. I have a wrapper class (CCrystalReports) that uses the CR API (not the com object). The wrapper has been used successfully in several single threaded apps. I've tried this two different ways with different, but always disappointing :(( , results. 1. Make CCrystalReports a member of the Worker thread class. This mode of operation had no memory problems as far as I can tell. Crystal Reports, however, failed to open the report file in this configuration. 2. Make CCrystalReports a dynamic in a method called by the worker thread. (So it is automatically destroyed at the right time. This runs for awhile, then blows when trying to return from the method. The actual blow up occurs in yet another program. The app I have been discussing supports a COM interface. Another program uses this interface to submit requests to the app, which then dispatches them to worker threads. The blowup comes in the Invoke call it returns the following error: (8007000e) Not enough storage is available to complete this operation. Any advice would be appreciated. This project has gone on too long! Thanks for the help, Bill
Hmmm. Are you using Oracle? From MSDN: ... applies to Microsoft OLE DB Provider for Oracle, version 2.1, 2.5... The following error message may appear when 5000 records or more are retrieved, and when each record contains 4 bytes of data: 8007000e Not enough storage is available to complete this operation... Note that the computer is not really out of memory... To work around this problem, return recordsets larger than 4 bytes... This problem was corrected in MDAC 2.6 Even if it isn't Oracle, my guess is that it's the DB provider setting that error. Let me try to understand. Application A supports a COM dispatch interface, and contains the worker threads. Application B calls into application A through the dispatch interface using Invoke(), but that call returns the 8007000e error code. Is this right? If so, is the call actually getting into Application A? I have a feeling it is, and that the error is being propagated all the way back from your DB layer. I could just be making this shit up though... :confused: J