No announcement yet.

weird errors

  • Filter
  • Time
  • Show
Clear All
new posts

  • weird errors

    I can't really post example code right now because
    my program is around 1300 lines long and I haven't
    gotten the same result from isolating anything. I'm
    just wondering if this is a known bug or if anyone
    has experienced this before. I'm using pb 3.1 and
    the function where the error occurs is recursive.

    When I place the variable 'inif', which is an integer,
    in the watch window and then step through the program
    I get:

    inif: Syntax Error

    this occurs with a few different variables, but not
    all. Thanks for any help. If I can isolate some
    code that causes the same problem, I'll post it.


  • #2
    First, do you have $ERROR ALL ON in your code? Since the Function is recursive, have you made the stack size large enough to cope with it?

    Next, if you print the variable to a file (rather than watching it in the debugger), does it's value show as being correct?

    Basically, my feeling from your brief description is that it could be a memory corruption problem due to errant code writing beyond an array boundary, or some other memory-relaated issue. It could also be a memory manager problem... what platform and EMS/XMS manager are you using?


    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    mailto:[email protected]


    • #3
      I don’ t know if this will help nor if it applies to 3.1, however, just to be watching the var in the reccomended way, make sure you are asking to watch inif% (from the PB/DOS 3.5 help:
      When selecting a PowerBASIC variable to watch, you must always append a type specifier, even if your source code doesn't require one



      • #4
        Thanks Lance and Davide. It turned out to be the stack,
        but all is working well now. I appreciate the help.



        • #5
          Not only is it, per the book, that you have to specify the variable
          type to watch it, but specifying the variable type on **ALL** of
          them throughout the source is, to me, helpful!

          Not only is it so much simpler to keep track of all of them as
          to what they are, visually, but there is a hidden benefit!

          If, for some oblique reason, one wants to port the source to,
          say, C++ or C .. you can then let the translator make a
          common coding technique pass.

          You can tell the translator to append an ".int" to all the source
          instead of that "%", or use ".lng", for the "&" and voila! Instant
          ability to carry that same comforting quick look familiarity with
          your 'same-name' variable in C or C++!

          Until you've faced it, you have no idea how comforting it is to be
          able to 'visualize' variables at sight in four times the total
          source code slurry, as opposed to our WONDERFUL overview we have
          in PowerBASIC ...

          If my foggy memory is correct, I think it was the Microsoft folks
          in the Visual Basic world, that wanted to focus throwing away these
          variable types in the source on a source-wide basis. The 'desired'
          position, I think I recall, was to do all this declaration at the
          top of the program, then not carry them afterward!

          I could be totally wrong in that memory.

          But when yo get up to 700-2000 variables per program, it sure seems
          a lot easier to be able to instantly spot of what kind they are.
          It also makes it, to my view, far easier to keep from making the
          error of calling it one kind of variable in one place in the code,
          then getting off a few nested SUB's deep in it, and getting it
          wrong by 'default' of in a SUB or function...

          Just $.02 worth here...

          Mike Luther
          [email protected]
          Mike Luther
          [email protected]


          • #6
            I recently encountered the same type of error in the watch
            variables. It turned out that the problem was with non-nested
            IF...THEN statements. When I put each IF on its own line, the
            problem disappeared. Thus I tried to put code similar to this:
            x=int(str$(value)):if x <1 then ....
            The if clause was on the same line as the "x=int...". When I put
            the IF clause on its own line, the problem disappeared. I hope
            this also helps.



            • #7
              Mr Bruening,

              Please avoid posting such anecdotal stories....

              If you have some code that shows the problem you casually describe above, then we would like to see it. There has NEVER (I repeat) NEVER been a single bug reported with IF/THEN statements IN ANY SHAPE OR FORM. Your message suggests problems that just do not exist.

              The problem David described to us was due to a stack overflow, as he reported 2 days ago.

              Thank you.

              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              mailto:[email protected]


              • #8
                Pat, often problems like the one you mentioned are due to memory corruption (OS, memory managers etc.), so IMO a possible explaination might be that merging two or more lines into a single one, occupied memory locations changed in a way that didn’ t cause the corruption anymore.
                It’ s that thing of when such problems disappear by simply moving parts of code from one place to another, which i think many of us experienced. I also experienced more than once these disappearings even just compiling on a different PC the *same* code with the same compiler settings.



                • #9
                  Lance ..

                  Mr Bruening,

                  Please avoid posting such anecdotal stories....

                  If you have some code that shows the problem you casually
                  describe above, then we would like to see it. There has NEVER
                  (I repeat) NEVER been a single bug reported with IF/THEN
                  tatements IN ANY SHAPE OR FORM. Your message suggests
                  roblems that just do not exist.

                  The problem David described to us was due to a stack
                  verflow, as he reported 2 days ago.
                  You might recall that I posted this same statement a long, long
                  time ago in relation to large programs. I've posted it and
                  variations on this theme more than once. And been chastised
                  also for it as .. "Your memory manager is faulty.

                  I admit memory managment for us all is a problem, Lance. But
                  I've asked, and never been told, exactly what the 'standard' is
                  to which we must comply for these things in order to run
                  PowerBASIC in an approved manner on an approved system.

                  Thus we all must somehow, get along, to help each other. It is
                  a two way street.

                  And it is TERRIBLY difficult to submit these to you folks,


                  On this last Internal Error 611 that prompted my latest post,
                  it is triggered by precisely what he I think he complains about.

                  If you simply change an IF / THEN construct as a multi-line form
                  to a single line in line form .. the error vanishes.


                  Now .. if you will kindly assure us that you won't ridicule me
                  for my miserably written code and that we are all truing to solve
                  this, I'll send you a common include file with about 600 public
                  variables and 3970 odd lines of code which, at least here do
                  just about what he says.


                  In *THIS* case, it produces an error 611.

                  I can tell you precisely the numeric line lable which makes it
                  happen, in this example.

                  I can absolutely guarantee you that in other cases, it can take
                  hundreds of hours of time to find out where in the Devil the thing
                  goes wrong, and when it does, you and others are correct, memoru
                  is corrupt. A variable that is needed at that point will be
                  corrupt. But the code will continue to execute, even with the
                  wrong value for the variable. And depending on whether the error
                  in the value is fatal or not, you either will abend the program
                  as a result of that one way or another, or .. your customer will
                  abend if the result is fatal to he or she.

                  I think that all code contains the propensity for errors.

                  I'll be perfectly happy to be proved wrong if I'm wrong and write
                  code badly.

                  I make more mistakes than I'll bet anyone here makes.

                  Should I submit this one in his, perhaps, defense?

                  From a production standpoint, after taking another twenty or so
                  hours of my life to trace it. I 'solved' the problem here when
                  I simply added about three lines of other code somewhere else
                  and the problem went away on its own.

                  Which is exactly what most of us are doing which hit this.

                  But I will try for us all if it's wanted and I won't get poked
                  with too sharp a stick for my miserable code..

                  In this case I was, after all these years, to *FINALLY* save a
                  single source code module for a single PBU, which only has
                  the one common include file in it .. which illustrates this
                  problem as seen here...

                  Mike Luther
                  [email protected]
                  Mike Luther
                  [email protected]


                  • #10
                    Lance Edwards!

                    I was just trying to help, not critize IF..THEN. I'm sorry
                    I ruffled your feathers.




                    • #11

                      I've gone ahead and submitted the entire source display that
                      evokes what I think you see. At least it, or a variation of it
                      does here. And furthermore, it produces an internal 611 error
                      code during compile time.

                      The code submitted can't be executed to show what happens when
                      the thought to be true error actually gets involved in code

                      That'a a *HUGE* job to illustrate, at least in my experience.
                      More important, and this is just a personal opinion based on
                      years of watching this difference of opinion, is something else.

                      It isn't in my experience, so much a factor of how EMS, and other
                      upper memory is put together on a box, which successsfuly runs the
                      code that counts, as it is when something abends in the code that
                      makes it break.

                      That's just an opinion.

                      Code which DOES work, seems to be a non-problem on many different
                      boxes with many different implementations of upper memory. It
                      seems, at least in my case not to be so important. On the other
                      hand when something goes wrong in the code, which, indeed can and
                      seems to be related to the toolset; how the program collapses into
                      what is the eventual failure we see ... may vary widely between
                      how EMS is set up, and what all else is involved such as operating
                      systems. Yes and even operating systems of the same general kind
                      as well as just different levels of them.

                      Lance has complained that it hasn't been shown so. There are by
                      my internal Email holdings, a substantial number of others who
                      feel that it is.

                      Thus regardless of whether or not 'e wants to beat me over it all
                      I've gone ahead and just sent the code to show up the 611 part of
                      this which I do see here.

                      We'll worry about what to do next on the basis of what that produces.

                      If I have to be the sacrificial goat, so be it.

                      Mike Luther
                      [email protected]
                      Mike Luther
                      [email protected]


                      • #12
                        Mike, i don’ t want to criticize you indeed (i think the contents of your posts are always very interesting, i learn a lot from them and i hope you keep them on), but i must say that you looked too hurried in candidating yourself as a victim. It’ s true that sometimes we saw insulting or offending posts here, made by people who just didn’ t like the subject discussed in the topic, but as far as i remember, these always came from people external to PB.
                        More important, on the other side, i saw posts made by users (included me, darn! ) resulting, intentionally or not, into a so unpleasant feeling that they simply had to be shot, but PB moderators professionally kept theirselves from replying in a corresponding unpleasant way.

                        I can assure that the only one time (out of a lot) when i have been able to make a variable watching problem replicable on different systems and i could put PB into the condition of replicating it, they gave me the most clear and useful feedback they could, and did all but making a victim of me.

                        I think the problem is that these forums, for which we should never get tired to thank PB, might negatively affect the image of PB products when a post, usually not by malice but by too approximative or emotional words, indirectely suggest the existence of bugs which aren’ t such. It’ s easy to happen because words are a rough approximation of thought in their nature, that’ s the main reason why IMO they should be used lightly and sparingly.