Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1273

Re: Basic ERL wrong after abort

Show all headers | View raw

On 07 Jan, in article
<de924ead-531c-4100-9787-ccd2cb79f5cc@m4g2000vbc.googlegroups.com>,
   Gerph <gerph@gerph.org> wrote:
> On Jan 7, 12:54 pm, Martin <New...@avisoft.f9.co.uk> wrote:
> > For some time I have been bugged by instances where a Basic program
> > has encountered an error, but the ERL of the error is always
> > (misleadingly) set to the very last line of the program (even if that
> > comes from a LIBRARY).
> >
> > This, in a large program, can cause far too much time wasted in
> > narrowing down where the real error actually is.

> In the case below you would use:
> *BTSDump -a
> ... lists you what code was being executed and will tell you that it
> was inside the call to Wimp_CreateWindow, which significantly narrows
> your investigation. 

That might help ... if I had it. Unfortunately I normally use the latest
version of RO to be produced (v5.16) which does not include it  :-))
I will have an experiment on RO4 and 6 later.

> Time spent investigating is limited by the number of calls to the
> failing operation and the complexity of the paths leading to them, and
> usually you narrow the problem by knowing what the code was doing at
> the time, excluding the code which isn't present.
[Snip TRACE info]
> In worst case, PRINT debugging is always useful.

Oh yes, I am very familiar with such debugging techniques - I have been
debugging code of various sorts for over 40 years! Indeed, I am the
developer of Reporter, a widely used RO debugging aid which can TRACE and
PRINT to a debugging window, among other things.
 
> More specifically, diagnosing that kind of error should be trivial -
> assuming that your incorrect operation hasn't blown away other things,
> in which case there's little that your error handler might be able to
> do to save you. That you don't get a line number in your error report
> is an irritance, but not one that is particularly difficult to
> address.

If the program is 30,000 lines of code, with over 900 SYS calls, it can
still take some time. I would just love to be able to reduce it if
possible.

[Snip my long program]

> Wow, that's overkill of a testcase...
> ---
> 5 ON ERROR PRINT REPORT$;" at line ";ERL:END
> 10 PRINT "START"
> 20 SYS "OS_File",0,&12345678 : REM Abort here
> 30 PRINT "END"
> ---
> is simpler to see and doesn't confuse the issue by introducing a
> Wimp_Initialise which adds its own environment handlers.

Yes, that is much simpler, and as you say excludes the Wimp. Thanks.
Although the abort is in DEEUtils here, confusingly!

> > I *think* the only instances I have seen of this have been Aborts, and
> > may only have been within SWIs (rather than just in assembler code).

> There's probably a bunch of other instances but the SWI will be your
> most common. Faults in callback handlers and SWIs would also cause the
> problem.

Having read this, I did some more experimentation. I now think that it
can happen in any external code that changes the line pointer r12. It is
just that SWIs probably always change it! The following program
illustrates this...

    10 : REM Abort3
    20 :
    30 : ON ERROR PRINT REPORT$;" at line ";ERL:END
    40 :
    50 : DIM code% 20
    60 : P% = code%
    70 : [
    80 : ; MOV       r12,#&ff0000
    90 : LDR       r2,[r0]
   100 : MOV       pc,r14
   110 : ]
   120 :
   130 : A% = &12345678
   140 : B% = USR code%
   150 : END
   160 :
   170 : REM last line

As it stands, the correct ERL of 140 is given. 
Remove the comment from line 80, and ERL becomes 170.

> BASIC does not install abort handlers (or any of the other handlers),
> if I remember rightly - and bear in mind that my memory is failing as
> I've not looked at the source to BASIC in 7 years or so. As such it
> performs no additional operations when an error occurs, leaving it to
> the default handler, which will just raise an error through the normal
> mechanism.

That is correct, AFAIK. It only installs the normal Error, Escape, Exit,
UpCall environment handlers, but no Abort handlers. 

> The BASIC error handler uses its current executing line pointer... 
[Snip how it searches]
> If it cannot find the line pointer in the program it is left with ...
> the last line in the program.

Yes, agreed.

> On entering the environment error handler all registers are undefined
> except R0 which contains a pointer to the environment error workspace
> (PC, and error block for the error). Because all the registers are
> undefined, you cannot rely on R12 (or any other register) being
> anything useful - and indeed it isn't when an abort occurs.

Thanks for that clarification. What had confused me in the past was that
in many cases r12 WAS still valid, so the correct ERL was found. But this
is just chance.

> The error handler also performs other operations which you might not
> want to occur in an error handler, but which make the most common
> cases safer.

And it will lose any information on the Basic stack back to the last
active error handler. Which may include losing r12, I suspect! I am
wondering if it might be possible to recover it in the environment error
handler when it is first called. I will do some further investigation.

> There are obviously many problems with this method, and there are a
> number of ways in which it could be improved.

Sadly, all too true of ALL programs!

> My memory is rusty, so I could be wrong about some of the detail, but
> I believe that's the process which results in the behaviour you are
> seeing.

Rusty or not, it has helped to clarify what is happening. Many thanks for
your input. I (and I suspect many others) miss your regular wisdom and
knowledge in the RISC OS scene.

Thanks
Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Basic ERL wrong after abort Martin <News03@avisoft.f9.co.uk> - 2012-01-07 12:54 +0000
  Re: Basic ERL wrong after abort cferris@freeRemoveuk.com.invalid - 2012-01-07 13:49 +0000
    Re: Basic ERL wrong after abort Martin <News03@avisoft.f9.co.uk> - 2012-01-07 15:22 +0000
  Re: Basic ERL wrong after abort Gerph <gerph@gerph.org> - 2012-01-07 06:11 -0800
    Re: Basic ERL wrong after abort Martin <News03@avisoft.f9.co.uk> - 2012-01-07 17:56 +0000
      Re: Basic ERL wrong after abort wpb <w.blatchley@yahoo.com> - 2012-01-08 04:05 -0800
        Re: Basic ERL wrong after abort Martin <News03@avisoft.f9.co.uk> - 2013-05-19 17:42 +0100
          Re: Basic ERL wrong after abort Alan Adams <alan@adamshome.org.uk> - 2013-05-19 18:42 +0100

csiph-web