Error trap handling is a large part of my program work. For debugging
from users I write a simple append file on their disk. The executable
name, log unit number, PowerBASIC ERR and ERL, date and time and sometimes
free memory values and stack space can be gained from each append line.
PowerBASIC's error trap capabilities are a HUGE benefit. Try hand writing
code in C/C++ to equal it, even though it is keyed to numeric line lables.
So NUMERIC line lables for PB error service are well placed in some critical
points, yet most lines, with utmost care where no lables are needed, have
no lables in my source code. That to remove another source of confusion.
Long before PB 3.5, I chose to 'reserve' a block of the 64K available
BASIC line numbers for common SUB's and FUNCTIONS for core lower and
mid-level common functions. The concept has been stable for years. My
entire core lowest level suite-wide video, string and file operations on
standard PB code are all common library modules assigned to the 50,000
to 59,999 line number range. They always retain the same code and line
numbers. Now please consider the following corruption I can't figure out!
Here are error log results for one client site on four different boxes
with different hardware mix, ages, raw hardwired memory size. We can't
really force people to keep hardware at the same level there, even though
my code suite support files on that server have a total of only TWO (2)
hours of failure down time in now EIGHT years of 24X7 service in my suite
under the OS/2 superb operating system and network capability there!
In the combined error log below, a program is followed by log unit, PB ERR
number, PB ERL NUMERIC line number, date and time. Two programs also seek
to return available free string memory, free high memory and free stack
space. But note the FAILURE to report that also in some cases. That's a
curious point as the line is generated in these executables by exactly the
same compilation that DOES provide that memory data for some of the errors!
Five separate programs show unreasonable errors just AFTER the same little
SUB. And the failure to show any memory values in the space available
print points indicate corruption issues to me. The SUB which produces the
data values for the memory in NAMES.EXE is called at the start of each new
or edit function for the program, for example.
What produces this PB 'error' 70 (Unable to write to a protected disk)
and 5 (Illegal function)? Here is a declaration. Please, If this utmost
core level SUB occurs hundreds of times in a suite and every program of
over a hundred has to use the results of it; the smartest way to use a
CORE level function is to use PUBLIC variables for it in suite-wide. I do,
from a comman include file so there are no declaration errors. The SUB
in question does nothing other than to recover the cursor line and postion.
It put that in two PUBLIC short integers variables. That's all.
Here is all this tiny SUB does!
And in the five programs above, over 60 different uses similar to the
below are used from whence the logged errors above arose:
That NUMERIC line number 7590 in the example above is there for a VERY
good reason. When you hit an error trap, like the NUMERIC line number
50421 trap above, go on below it with no further NUMERIC line lable,
you still show the 50421 error line from the SUB, even though the error may
be at a line WAY below the reported 50421. Not here. In no case here is
there ever anything other than a simple integer equate for more than a
few lines below, followed by yet another hard NUMERIC line number which
should trip the PB error mechanism pointer to it, not the one shown.
If the error trap routine is operating correctly, the trap above has to
be following the SUB and before the next hard NUMERIC line lable.
And in every case of the reported errors for the problem above there is FIRM
ability to know from all the source, that the error 70 or 5 is restricted
only to code just after that SUB - for simple integer equates. In every
case, unless there is a compiler error that blows this up, the cursor has
to be somewhere legitimate on the screen for the request made to even
return error free from the SUB! And if that were the case, we would get
the error 50420 line, not the 50421 line.
So how in whatever can you have any simple integer equate produce this?
How do we get any totally irregular incidence for an ERROR 5 illegal
function call out of this game, let alone an ERROR 70 for failure to be
able to write to a protected disk for just the above integer equates?
That unless this is memory corruption issues?
An associate of mine who is a lot more informed than I suggests the
following. To help prove memory corruption, right at the first of the
programs, declare a unique new PUBLIC integer variable. Very early on
in the program set it to a specific value. Never look at it again in
the program, except to print it out in my error log error line report!
If the value printed on the error line is different than the initialized
value, we have 'proof' memory is corrupt. Then we also have a beginning
point that might help find exactly where the application is failing.
Comments?
------------------
Mike Luther
[email protected]
from users I write a simple append file on their disk. The executable
name, log unit number, PowerBASIC ERR and ERL, date and time and sometimes
free memory values and stack space can be gained from each append line.
PowerBASIC's error trap capabilities are a HUGE benefit. Try hand writing
code in C/C++ to equal it, even though it is keyed to numeric line lables.
So NUMERIC line lables for PB error service are well placed in some critical
points, yet most lines, with utmost care where no lables are needed, have
no lables in my source code. That to remove another source of confusion.
Long before PB 3.5, I chose to 'reserve' a block of the 64K available
BASIC line numbers for common SUB's and FUNCTIONS for core lower and
mid-level common functions. The concept has been stable for years. My
entire core lowest level suite-wide video, string and file operations on
standard PB code are all common library modules assigned to the 50,000
to 59,999 line number range. They always retain the same code and line
numbers. Now please consider the following corruption I can't figure out!
Here are error log results for one client site on four different boxes
with different hardware mix, ages, raw hardwired memory size. We can't
really force people to keep hardware at the same level there, even though
my code suite support files on that server have a total of only TWO (2)
hours of failure down time in now EIGHT years of 24X7 service in my suite
under the OS/2 superb operating system and network capability there!
In the combined error log below, a program is followed by log unit, PB ERR
number, PB ERL NUMERIC line number, date and time. Two programs also seek
to return available free string memory, free high memory and free stack
space. But note the FAILURE to report that also in some cases. That's a
curious point as the line is generated in these executables by exactly the
same compilation that DOES provide that memory data for some of the errors!
Five separate programs show unreasonable errors just AFTER the same little
SUB. And the failure to show any memory values in the space available
print points indicate corruption issues to me. The SUB which produces the
data values for the memory in NAMES.EXE is called at the start of each new
or edit function for the program, for example.
Code:
"ENTRY.EXE Log # ","1"," err# ",70," line",50421,"01-31-2005","18:26:53" "INVENT.EXE Log # ","1"," err# ",70," line",50421,"01-20-2005","16:08:59" "PRLIST.EXE Log # ","1"," err# ",70," line",50421,"03-14-2005","16:16:01",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"03-17-2005","11:53:38",8174,227600,3788 "PRLIST.EXE Log # ","1"," err# ",70," line",50421,"04-05-2005","17:33:23",0,0,0 "ENTRY.EXE Log # ","1"," err# ",70," line",50421,"04-08-2005","07:29:30" "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-14-2005","17:12:53",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-17-2005","18:36:05",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-17-2005","18:55:36",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-17-2005","18:58:49",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-17-2005","19:05:28",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-18-2005","07:28:22",8174,225552,3788 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-18-2005","07:30:31",0,0,0 "NAMES.EXE Log # ","1"," err# ",5," line",50421,"04-18-2005","08:36:12",0,0,0
What produces this PB 'error' 70 (Unable to write to a protected disk)
and 5 (Illegal function)? Here is a declaration. Please, If this utmost
core level SUB occurs hundreds of times in a suite and every program of
over a hundred has to use the results of it; the smartest way to use a
CORE level function is to use PUBLIC variables for it in suite-wide. I do,
from a comman include file so there are no declaration errors. The SUB
in question does nothing other than to recover the cursor line and postion.
It put that in two PUBLIC short integers variables. That's all.
Code:
PUBLIC CURL%, CURS% DECLARE SUB PK50420() ' REMCURS:
Code:
SUB PK50420() PUBLIC ' REMCURS: ' Globals are CURL%, CURS% 50420 CURL% = CSRLIN CURS% = POS(0) 50421 END SUB
below are used from whence the logged errors above arose:
Code:
CALL PK50420() ' REMCURS: GXD% = CURL%' Recall line GYD% = CURS%' Recall column 7590 ' PB err spacer with hard line number for trace support.
That NUMERIC line number 7590 in the example above is there for a VERY
good reason. When you hit an error trap, like the NUMERIC line number
50421 trap above, go on below it with no further NUMERIC line lable,
you still show the 50421 error line from the SUB, even though the error may
be at a line WAY below the reported 50421. Not here. In no case here is
there ever anything other than a simple integer equate for more than a
few lines below, followed by yet another hard NUMERIC line number which
should trip the PB error mechanism pointer to it, not the one shown.
If the error trap routine is operating correctly, the trap above has to
be following the SUB and before the next hard NUMERIC line lable.
And in every case of the reported errors for the problem above there is FIRM
ability to know from all the source, that the error 70 or 5 is restricted
only to code just after that SUB - for simple integer equates. In every
case, unless there is a compiler error that blows this up, the cursor has
to be somewhere legitimate on the screen for the request made to even
return error free from the SUB! And if that were the case, we would get
the error 50420 line, not the 50421 line.
So how in whatever can you have any simple integer equate produce this?
How do we get any totally irregular incidence for an ERROR 5 illegal
function call out of this game, let alone an ERROR 70 for failure to be
able to write to a protected disk for just the above integer equates?
That unless this is memory corruption issues?
An associate of mine who is a lot more informed than I suggests the
following. To help prove memory corruption, right at the first of the
programs, declare a unique new PUBLIC integer variable. Very early on
in the program set it to a specific value. Never look at it again in
the program, except to print it out in my error log error line report!
If the value printed on the error line is different than the initialized
value, we have 'proof' memory is corrupt. Then we also have a beginning
point that might help find exactly where the application is failing.
Comments?
------------------
Mike Luther
[email protected]
Comment