Announcement

**Tom Hanlin** · 28 Jan 2003, 03:49 PM

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

**Joep van Steen** · 29 Jan 2003, 12:04 AM

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

**Davide Vecchi** · 29 Jan 2003, 12:26 AM

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]

**Joep van Steen** · 29 Jan 2003, 03:32 AM

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

**Tom Hanlin** · 29 Jan 2003, 02:44 PM

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

**Joep van Steen** · 29 Jan 2003, 11:43 PM

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

**Lance Edmonds** · 30 Jan 2003, 03:04 AM

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>

**Joep van Steen** · 30 Jan 2003, 03:44 AM

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

**Michael Mattias** · 30 Jan 2003, 03:56 AM

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

**Mike Luther** · 30 Jan 2003, 04:12 AM

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

**Michael Mattias** · 30 Jan 2003, 04:31 AM

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

**Joep van Steen** · 30 Jan 2003, 06:09 AM

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

Announcement

What is error 154?

What is error 154?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment