No announcement yet.

What is error 154?

  • Filter
  • Time
  • Show
Clear All
new posts

  • What is error 154?

    Do not have details right now. Is reported by a user of my program
    but I can't even find a description for the error in reference guide.

    Also, is there specific types of errors that 'bypass' a global
    error trap ... this one seems to do so anyway ...

    "Error 154 at pgm-ctr 1012049"


    [This message has been edited by Joep van Steen (edited January 28, 2003).]

  • #2
    There is no such error, which may just be the reason it isn't getting
    caught by your error handler. What you've got is a bug that is trashing
    your program in memory. There are any number of possible causes, so you
    really need to get as much information as you can from the user.

    Tom Hanlin
    PowerBASIC Staff


    • #3
      Okay ... Will try to get that info. But what info ... ?

      Guide me little here, please. Am I looking for a bug in my program then,
      or maybe some 'physical' memory issue on the clients PC?
      Or memory configuration, like emm386 etc.., does that seem relevant?

      So, should I ask him to run a memory tester or something?

      I have never had the error before, and there isn't much I changed
      in the program. The major change is, that it is compiled as a
      chain file. So I basically took my code and compiled as chain
      instead of an EXE.

      The EXE that 'launches' the chain simply checks if the program
      will run in demo mode or 'full' mode based up on the hardware
      profile of that machine (I scan PCI bus and create an ID from
      ID's of PCI devices). Based up on that ID it executes the chained
      module, using a common value to let the program know if it is
      in demo mode or not.

      Kind regards,



      • #4
        If i was in your shoes i'd first try to have him doing his best to find a way to replicate the error. This would allow you a lot of tests to investigate the cause.

        Davide Vecchi
        [email protected]


        • #5

          Yes, I asked him to repeat steps that resulted in the error.

          >There are any number of possible causes

          What are examples of causes? Just a few.

          One other change is (although there's hardly any gain), that in the PBC
          there's an option to shell to DOS. I never used MEMPACK before,
          but now I do.

          What happens when you return to the program with this compressed heap
          and string segments?

          Kind regards,




          • #6
            Knowing what the user was doing when the program crashed will tell
            you much about what the program was doing when it crashed, which is
            an important lead in tracking down bugs.

            MEMPACK can trigger what you might call "latent bugs". If something
            has damaged the normal memory layout, MEMPACK's reorganization of
            memory will tend to bring the problem to light.

            Memory problems are, roughly, caused by unintentionally overwriting
            the wrong area of memory. This can be done in any number of ways:
            using array index 16 when the array only has 14 elements, using one
            of the POKE statements (or a pointer) with a bad address, having
            too much recursion (calling a function too many times without it
            returning, or having too many GOSUBs without RETURNS, etc), ...

            Tom Hanlin
            PowerBASIC Staff


            • #7

              Okay. Well, my program is a program for recovering deleted/lost
              partitions, trashed boot sectors, MBRs and also allows previewing
              of FAT and FAT32 partitions that are bad or lost.

              The stuff for previewing is 'old', I am using it for years now,
              thousands of people have been using it and I have never seen this
              error before.

              This user was actually previewing a FAT16 type partition. I think
              it is safe to say that at least 100.000 times this has been done
              before, again never saw this one.

              Is this possible: User mentioned he 'shelled' to DOS. Now assume
              he ran some piece of software there that caused memory corruption,
              is that possible?

              I can not reproduce this error with that build of the program. I
              have asked the user to try do to it again. Waiting for that now.

              If he can not reproduce this again, I guess I just can wait for
              the next one, feel it pretty much impossible to get to the exact
              cuase of this error right now.

              Thanks for you help so far ... BTW, not using any GOSUB or peeking
              and poking.

              And I ask again. During the years I have worked with PCs, I have
              seen really weird errors due to 'bad' memory or funny acting
              memory managers. Programs would throw up error messages that had
              nothing to do with memory. Swapping memory fixed it. Is bad memory
              a possible cause I can I exclude that option?

              Kind regards,





              • #8
                The first step in debugging such a problem is to add $ERROR ALL ON to ensure that the problem is not simply an untrapped error, for example, caused by writing beyond an array boundary (naturally this could only occur if BOUNDS testing was disabled).

                Solving memory corruption issues can be difficult since the use of pointers, inline assembler and Process memory will require that you validate each target address, etc.

                Bascially, you're going to have to get your hands dirty with some low-level debugging of your code. $ERROR ON ALL can often solve these problems very qwuickly, especially in the case of bounds or range errors.

                However, shelling to another app _can_ do any amount of damage if that app steps over areas it shouldn't (since DOS apps will share the same address space).

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


                • #9

                  Yes, that's a good first step ... It is good you do not exclude
                  the obvious in your advise

                  Presented an error right away.
                  Error 408 ... still the thing that confuses me is, that if I
                  compile $error all off and have a look at 'get info', there are
                  no segmets at all that exceed 64 Kb. As a matter of fact the
                  'fullest' one says 59 Kb.

                  Anyway, to be on the safe side I'll add some $segment statements.

                  Kind regards,





                  • #10
                    Error 154 at pgm-ctr 1012049
                    Um, what is the source code line pointed to by Compile/Find Error/1012049?

                    That should give you a big hint.

                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]


                    • #11
                      Mike ..

                      Um, what is the source code line pointed to by Compile/Find Error/1012049?

                      That should give you a big hint.
                      Ordinarily it does. But when the issue of the IDE and PDB being out of sync
                      with where the program is actually executing, it can make it very difficult
                      to produce really meaningful information from the stated excution point.

                      It will point to lines at which it is impossible for the stated error to
                      exist at all because the line or many lines around it has nothing to do or
                      could have nothing to do with the stated error!

                      I've attempted to try to do a research project through logging of the issue
                      over years worth of this misery now. What I've wanted to prove was that
                      the error displayed with the above code location method is in step and off
                      from the IDE/PBD error display as to where the code is actually executing.
                      However, I'm just not good enough to be able to chart it out.

                      The issue is particularly difficult to even try to trace in CALL's into nested SUB's.

                      However, for most folks, I suspect that the question you posed is a very
                      good question. And if it turns out that he finds the above I cite is
                      true in his case too, maybe he can provide the exact evidence to get it
                      corrected. I've never been able to do that and it remains in the product
                      at least here.

                      By mentioning this, if he stumbles on to this, at least he will know
                      how to adjust his thinking about tracing the problems.

                      A trick I often use to get a handle on this in the area where the out
                      of sync execution location display is important is to use a pile full
                      of the following error kludge lines:

                      DMY% = 1
                      DMY% = 2
                      DMY% = 3
                      DMY% = 4
                      DMY% = 5
                      DMY% = 6
                      DMY% = 7
                      DMY% = 8
                      ' And so on .. sigh

                      At least when you get an error throw, by temporarily seeding the source
                      with the above technique, and tracing the value of DMY%, you will know
                      how many lines off sync the IDE/PDB and also the location throw number
                      above is running. You can often work around a disparity of a value of
                      two or three lines. But when it gets beyond that I'm simply not able to
                      make any sense at all out of most of the de-bugging display.

                      At that point, as we both know from earlier comments, what you earlier
                      noted as a term "Cheese debugging", with the use of a hand set break
                      point and discrete printed variables, will be the only way to trace these
                      issues from a practical standpoint. I keep the following little snip
                      on the disk that I <CTRL K R> into the area to start tearing things
                      apart to look for the errors when the error doesn't produce a real trap
                      throw as he is indicating:

                      ' +++++++++++++++++++++++++++++++++
                      PRINT " Break @ "
                      PRINT " DMY% = ";
                      PRINT " = ";
                      LINE INPUT "For break <Z>: "; GGG$
                      IF GGG$ = "Z" OR GGG$ = "z" THEN SYSTEM
                      ' +++++++++++++++++++++++++++++++++

                      It is stored as BREAK.BAS and the other number deal above is stored as
                      BREAK2.BAS on my disk here.

                      Now .. at that point there is a possible chance to find the error where
                      before there is no reasonable way to make sense out of the screen display
                      for the IDE and PBD.

                      Of course, all bets are off if, as many times in the very large program
                      arena, simply adding the above makes the error just vanish! I find that
                      a fair percentage of the time, with very large programs and a couple
                      thousand variables, that will happen. Most important, there are a fair
                      number of cases involving source location indication in the above, when
                      the attempt to even set a break point to watch a variable in question
                      will complete destroy the entire development session in the formal use
                      of the IDE or PBD. The error seen will usually be the following in DOS-VDM's
                      in OS/2.

                      SYS3170: A program in this session encountered a problem and
                      cannot continue.

                      EXPLANATION: The process was ended because the program generated
                      an unhandled fatal user (non-system) exception through DosRaiseException.

                      ACTION: If you purchased this program, contact the supplier of the
                      program. If you are the developer of this program, refer to the
                      information in the register.
                      However, the same exact debugging session on pure DOS 6.2 boxes or in
                      a WIN-95/98 test case to attempt to trace the error, will result in a
                      totally locked box and no way to go forward without a full reboot!

                      If he hits this whole billibong, what I've suggested is the only way
                      I've ever found to continue to work with the product to go on and find
                      the actual error .. whether it has anything to do with even the displayed
                      error number which is supposed to make sense, or, as he has seen, one
                      which makes no sense at all.

                      The last such round of this I had was on December 8, 2002, with the
                      following corruption of the PMSHELL for OS/2 when this happens as in
                      the exact trace log for it here:

                      12-08-2002 20:48:56 SYS3170 PID 0dd3 TID 0001 Slot 003d
                      EAX=00000946 EBX=00000012 ECX=00000001 EDX=00000100
                      ESI=000042fe EDI=00003dbf
                      DS=42fe DSACC=**** DSLIM=********
                      ES=42fe ESACC=**** ESLIM=********
                      FS=0000 FSACC=**** FSLIM=********
                      GS=0000 GSACC=**** GSLIM=********
                      CS:EIP=2700:00003941 CSACC=00ec CSLIM=********
                      SS:ESP=5ffc:00009a1a SSACC=**** SSLIM=********
                      EBP=00009a36 FLG=000a2202
                      It occurred in an extensive rework of my core MENU SCREEN foundation
                      module, 3282 lines long as a third level nested SUB frozen at the moment

                      MENUSCRN PBU 85082 12-31-02 6:14a 3282 Menu screen I/O module
                      during changes for support for an on-going professional case currently a small
                      part of still being worked on now in excess of 26080 line program:

                      PRCHANGE EXE 409751 11-19-02 6:46a 26080 Profnl case editor
                      Most folks using PB won't even get that much help for the developer from
                      an operating system! But it's useless unless everyone is running the
                      same operating system and so on...

                      So if he is into the area where, as in the above, the error throw produces only
                      a pointer to the code, no useable error at all in the conventional ERR and
                      ERL sense, and the instant in the PBD the attempt to watch the suspected
                      variable produces the above SYS3170 error (actual fact!), then the only
                      possible solution to trace it, as far as I can tell, will be to add an old
                      fashioned break point and variable value printing technique you have so
                      eloguently referred to as "Cheese debugging"!

                      Often times, however, you will find an even more interesting scenario which
                      will hit you with the above style errors! He may find, as I sometimes do,
                      that if the operating system session doesn't collapse from the corruption
                      into the SYS3170 error game, he *CAN* get an actual numeric line pointer
                      to the problem if he will do the following.

                      In all my programs, just before the ON ERROR GOTO 0 at the unresolved
                      exit in my error trap section you will find the executable program
                      will be asked to leave a calling card to the developer:

                      22499 FL%(8) = FREEFILE '                       Select file
                      22500 OPEN "ERROR.LOG" FOR APPEND ACCESS READ WRITE SHARED AS #FL%(8)' Open error log file
                            WRITE #FL%(8), "NAMES.EXE Log # ", K$(56), " err# ", ERR, " line", ERL, DATE$, TIME$, PGT#, PGM#, PGS#
                            CLOSE #FL%(8) '                           Close file
                            FL%(8) = 0 '                              Free it
                            ON ERROR GOTO 0
                      You will find that in the case of the collapse such that you do not have
                      a formal visual ERR and ERL display, the program can sometimes help you trace that
                      even though the pointer location will not! Not all the time. Sometimes.

                      Now the above is only helpful *IF* you have a valid NUMERIC LINE LABLE to
                      which it can refer. As we've thrashed over many times here, that means
                      that the PB error routine help will go back to the last known NUNERIC
                      LINE LABLE for display.

                      Aha! Insight!

                      What are those variables PGT#, PGM#, PGS# doing in the above?

                      In all my programs I have the option to use a core level SUB to always
                      give me a running trace trap on memory status!

                      SUB DB49529 (PGT#, PGM#, PGS#, PMEM#) PUBLIC '                  CHKMEM:
                               ' GLobals are CURL%, CURS%, GX%, GY%, GFX%, Z6%, DMY%
                               CALL PK50420() '                       REMCUR:
                               CALL PK50661() '                       BRTWHTBLK:
                               Z6% = 0'                               Null error flag
                               PGT# = FRE("XX")'                      Calculate free space for strings
                               PGM# = FRE(-1)'                        Calculate free space in hi mem
                               PGS# = FRE(-2)'                        Calculate free space in stack
                                  IF PGT# < PMEM# OR PGM# < PMEM# OR PGS# < 150# THEN
                                     CALL PK50510() '                 C25HLD:
                                     PRINT "  Not enough memory: $"; PGT#; " F"; PGM#; " S"; PGS#; ", WAIT! or <Esc>ape program: ";
                                     CALL PK50302() '                 WAITKEY:
                                        IF Z0$ <> CHR$(27) THEN '     Not ready to exit yet
                                           GOTO DMEM1 '               Try again
                                        END IF
                                     Z6% = 26 '                       Set exit flag
                                     CALL PK50510() '                 C25HLD:
                                     CALL PK50430() '                 RETCUR:
                                  END IF
                                  END SUB
                      Obviously, that process is also calling further down core level screen
                      handling techniques for line placement, line clearing and so on. But you
                      can get the idea from the above how to develope the tools.

                      But Aha! More insight!

                      There will be times when you will not be able to recover any line numbers
                      and so on for a variety of reasons as has been explained above. More help
                      here. Recall that, although I wish that PB could act on NON-NUMERIC line
                      lables for error tracing, it can't. What to do? If you are using a master
                      error trap location information dump schema as I do here, then what you
                      can do is to simply seed one of those PGT#, PGM#, PGS# variables with
                      a NEGATIVE number. I've done this numerous times to trace errors which
                      are thrown during the development of Btrieve assembly language interface
                      routines. That's one of the places where an error in an in-line assembler
                      tool pops normally untraceable and not readily trapped errors.

                      If the program line sync error issue makes your debugging with it virtually
                      useless as to the IDE and PBD tools, you can seed your program with a
                      PHANTOM line counter variable AS IF IT WERE LINE NUMBERS for use! Then
                      all you have to do to trace the actual progress of the program, where it
                      won't otherwise trap to tell you that, is to either read that variable from
                      a "Cheese debugging", toolette, or ... sometimes get a user's box to give
                      that to you to the error log on the disk .. before it collapses into
                      oblivion, or blows away the operating system session.

                      We all learn from our mistakes, hopefully. I've just learned some more
                      from posting this! I'm stupidly not providing a SEPARATE line number
                      tracer as a global in my suite to add to the above technique! If I've
                      gone to the trouble to do all this for tracing purposes, surely one more
                      global variable in the suite can't hurt... and will help preserve even
                      the memory available dump as well. I assure you, that'll change here
                      from now on.

                      As to help from PB on all this? Not likely, but that's not at all said
                      in criticism of PB.

                      It's for sure that at a very large level of code size, variables, and so
                      on, plus with the great differences in operating systems in use, that it
                      is very difficult or impossible to ever submit any of this to the PB crew.

                      And yes .. I'm very understanding about, "If we can't reproduce the error
                      here, we can't fix it!" I have enough of my own, thank you! 2


                      So please .. all I've done here is try to give a user a decent understanding
                      of several other things which can be done to find and display errors
                      when the tool itself comes apart. It does. And when it does, please
                      don't shoot the mule here for plowing through all of this to give you
                      the chance for salvation anyway.

                      Mike Luther
                      [email protected]

                      [This message has been edited by Mike Luther (edited January 30, 2003).]
                      Mike Luther
                      [email protected]


                      • #12
                        But when the issue of the IDE and PDB being out of sync
                        PDB/IDE? Huh? Mr van Steen said the USER gave him the error message (and he should be counting his blessings, as most users would report this as, "Broke. <End of Information>")

                        And of course the IDE and PDB are out of step. The debugger adds executable code, so the PDB-compiled EXE does not match the PB (or PBC) compiled EXE. But so what? If you are running in a stepping debugger, you don't really need the 'external' reference to "which line of code is executing."

                        I don't do much (any?) PB/DOS anymore, but in all the years I did Compile/Find Error performed excellent duty. Really one of the "most missed" tools in theWIndows compilers, although the new #TOOLS stuff in CC3/Win7 (TRACE, CALLSTK, etc) are quite useful.


                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]


                        • #13

                          (and he should be counting his blessings, as most users would report this as, "Broke. <End of Information>")

                          I have tried your suggestion already, compile > find error >
                          enter address ... Don't exactly know what the repsonse was, but
                          basically the IDE could not so anything with. Address not found
                          or so.

                          I have changed code since then already, so now I guess it doesn't
                          make sense anyway.

                          I am not really sure how the message of Mike will help me.

                          It's a lot of text and I am not into shooting mules anyway.

                          Most errors I can can solve because I always do a lot of logging.
                          Immediately after startup I open a file for the purpose of
                          logging. As I do a lot of disk reads/writes I dump sectors in hex.
                          I keep track of available memory and stack space etc. Error traps
                          will always dump that kind of info to the logfile as well.

                          Apart from trapping errors the logfile is used for supporting
                          users with the actual data recovery. Without them telling me I
                          can see their MBR, their partitions, partitions I found but are
                          not there etc.

                          In this case the log I received did not show any out of the
                          ordinary. He was doing stuff thousands had done before him.

                          The only obvious error that was caught during compile time was
                          a segment overflow. That I fixed. Since this error seems so rare
                          I assume it is fixed until proven otherwise.

                          Kind regards and thanks for all the help!