Announcement

Collapse
No announcement yet.

Limitation On The Size Of A Sub?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Limitation On The Size Of A Sub?

    Hi, there,

    The program I wrote calls a Sub in a DLL
    that is compiled with PB/DLL v.5.

    A user is required to fill in the sub with
    all the code he wants, mainly lots of
    math calculation. Since the users are not
    programmer oriented, they ask to use Undeclared
    variables in the sub, which means they are
    default as Local-type

    Now, for one user, the code in the sub has more
    than 5000 lines, around 1000 local double-type
    variables. It compiled OK with the "DLL does not
    require stack allocation" shown on the compile
    window.

    However, a call to this sub from the VB5 program
    causes "Error 28, stack overflow" every time.

    So, what are the limits of:
    1. number of local variables within a sub/function?
    2. number of lines of code within a sub/function?

    Any suggestion of working around the "stack overflow"?

    Tianyi Zhai


    ------------------

  • #2
    I'd guess that the DLL is using the EXE's stack space, so the limitation
    here is probably based on the size of the stack that VB allocates.

    Each of your users is compiling programs with PB/DLL...? Do they each own
    a copy of PB/DLL, then?

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Comment


    • #3
      If that's the case, how can the VB stack, be increased?

      Yes, we have more than 15 engineers wondering around south-east,
      and each of them as a legal copy installed on his pc.

      ------------------

      Comment


      • #4
        PB version 5, VB - stack???
        Weird
        Stack is afaik related to ram+diskmemory

        ------------------
        hellobasic

        Comment


        • #5
          I don't know what size stack VB uses or whether it's possible to change this.
          Though, actually, it seems odd that you'd run out of stack space. Possibly your
          VB program is dimensioning some large local arrays? Or perhaps there's a
          recursion error in the SUB or main program... worth examining.

          ------------------
          Tom Hanlin
          PowerBASIC Staff

          Comment


          • #6

            From my VB6 'programmers guide' (just as clunky as the compiler)...

            ...the default Visual Basic stack size is 1MB, it may grow beyond this, however...
            ------------------
            Kev G Peel
            KGP Software, Bridgwater, UK.
            mailto:[email protected][email protected]</A> http://www.kgpsoftware.com
            kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

            Comment


            • #7
              Originally posted by Tianyi Zhai:
              However, a call to this sub from the VB5 program
              causes "Error 28, stack overflow" every time.
              Should you maybe (if possible) make a test program in PB that calls the dll, to verify that it is a VB problem?



              ------------------
              Best Regards
              Peter Scheutz
              Best Regards
              Peter Scheutz

              Comment


              • #8
                Incorrect passing of parameters when calling a DLL will result in out of stack space in VB. Is the DLL function recursive? Can you call it successfully from PB?

                Can you post the function definition and an example of exactly how it is called from VB?

                [This message has been edited by Ron Pierce (edited June 22, 2001).]

                Comment


                • #9
                  Thank to all for your help!

                  The VB routine that calls the PB DLL is passing two one-
                  dimenssion arraies to the PB DLL. These two arraies are
                  defined inside the VB as PUBLIC.

                  The sub inside PB/DLL called by VB is defined like:
                  SUB Performance (PointName() AS STRING, PointValue() AS DOUBLE, BYVAL Points_In_PDB AS INTEGER) EXPORT

                  This has been working fine for past five years.

                  Only this time a field engineer wrote a fairly long code for
                  the SUB Performance. The arraies passed have about 950 elements,
                  that means there are at least 950 local double-typed variables,
                  plus some more intermittent ones

                  There are about 4000 lines of code in this one sub, which are
                  dealing with math calculation. There are a lots of *, /, ^, SQR,
                  etc.

                  I checked the stack loaded by using the VB Stack Viewer. There
                  were only four VB Sub/Functions loaded in the stack. All these
                  Sub/Functions are small(less than 50 lines of code, without loop
                  operation involved). The Stack Viewer showes that the PB/DLL is
                  the only other Sub in the Stack.

                  I tried debugging the PB/DLL. The process always jumps to the end
                  at the middle of the Sub without giving error message.

                  Right now I am checking the code line by line. Hope to find
                  something fishing. I will certainly post the result here.

                  Tianyi Zhai



                  ------------------

                  Comment


                  • #10
                    Well, I checked the PB/DLL SUB that caused "Stack Over Limit"
                    error when calling from a VB5 program.

                    The REASON of the error is the wrong parameters passed to
                    math functions inside the PB/DLL SUB:

                    LOG(A): A < 0
                    SQR(B): B < 0

                    I wish to thank to everyone who responsed to my original post, you
                    led me to working on the math code instead of worrying on the
                    Local/Global.

                    Tianyi Zhai



                    ------------------

                    Comment

                    Working...
                    X