Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Stack size question

Stack size question

Scheduled Pinned Locked Moved C / C++ / MFC
questiondata-structuresperformancehelp
4 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B Offline
    B Offline
    Bill Wilson
    wrote on last edited by
    #1

    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

    J 1 Reply Last reply
    0
    • B Bill Wilson

      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

      J Offline
      J Offline
      Joaquin M Lopez Munoz
      wrote on last edited by
      #2

      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

      B 1 Reply Last reply
      0
      • J Joaquin M Lopez Munoz

        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

        B Offline
        B Offline
        Bill Wilson
        wrote on last edited by
        #3

        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

        J 1 Reply Last reply
        0
        • B Bill Wilson

          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

          J Offline
          J Offline
          Jamie Hale
          wrote on last edited by
          #4

          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

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups