Announcement

Collapse
No announcement yet.

What is error 154?

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

  • Joep van Steen
    replied
    Hello,

    (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!

    ------------------
    Joep

    http://www.diydatarecovery.nl

    Leave a comment:


  • Michael Mattias
    replied
    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.

    MCM

    Leave a comment:


  • Mike Luther
    replied
    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:

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

    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:

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

    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
    C:\OS2\PMSHELL.EXE
    126320dc
    e11cfee7
    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
    as:

    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:

    Code:
    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!

    Code:
    SUB DB49529 (PGT#, PGM#, PGS#, PMEM#) PUBLIC '                  CHKMEM:
             ' GLobals are CURL%, CURS%, GX%, GY%, GFX%, Z6%, DMY%
             CALL PK50420() '                       REMCUR:
             CALL PK50661() '                       BRTWHTBLK:
    DMEM:
             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: ";
    DMEM1:
                   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

    GDRFC!

    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).]

    Leave a comment:


  • Michael Mattias
    replied
    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.

    MCM

    Leave a comment:


  • Joep van Steen
    replied
    Hello,

    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,

    ------------------
    Joep

    http://www.diydatarecovery.nl

    Leave a comment:


  • Lance Edmonds
    replied
    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).

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

    Leave a comment:


  • Joep van Steen
    replied
    Hello,

    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,



    ------------------
    Joep

    http://www.diydatarecovery.nl

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Joep van Steen
    replied
    Hello,

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

    Also:
    >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,

    ------------------
    Joep

    http://www.diydatarecovery.nl

    Leave a comment:


  • Davide Vecchi
    replied
    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]

    Leave a comment:


  • Joep van Steen
    replied
    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,

    ------------------
    Joep

    http://www.diydatarecovery.nl

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Joep van Steen
    started a topic What is error 154?

    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"

    ------------------
    Joep
    http://www.diydatarecovery.nl

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