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

Groups > comp.sys.acorn.programmer > #1269 > unrolled thread

Basic ERL wrong after abort

Back to article view | Back to comp.sys.acorn.programmer

Contents

  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

#1269 — Basic ERL wrong after abort

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.

At last I have managed to create a small program to demonstrate this. I
know it is a stupid thing to write, but it is only to illustrate the
error handling problem. It is...

    10 : REM Abort        Gives ERL as last line of program. Why?
    20 :
    30 : ON ERROR PROCerror
    40 : SYS "Wimp_Initialise",300,&4b534154,"Test abort"
    50 : SYS "Wimp_CreateWindow",,123456789 TO h%  :REM <<error!!
    60 : END
    70 :
    80 : DEF PROCerror
    90 : DIM err% 256
   100 : $(err%+4)= REPORT$ +" ERL="+STR$ERL +" ERR="+STR$~ERR
   110 : SYS "Wimp_ReportError",err%
   120 : END
   130 :
   140 : REM This last line is ERL!

When run it gives an Data Transfer abort with ERL=140, the last line, not
50.

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

Can anyone throw any light on why this happens? 
The more technical, the better!

Thanks
Martin

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

[toc] | [next] | [standalone]

#1270

In message <524dd2a9c0News03@avisoft.f9.co.uk>
          Martin <News03@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).
> 
[snip]
> 
> 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).
> 
> Can anyone throw any light on why this happens? 
> The more technical, the better!
> 

Just tried this with no PROCerror but using 'DBEdit' this gives an
ERR 2: Internal error : abort on data transfer at &03971C84

Which with *where &03971C84

Address &03971C84 is at offset &00005F70 in module WindowManager

 
-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]

#1272

On 07 Jan, in article <82a3d74d52.cferris@cferris.freeuk.com>,
   <cferris@freeRemoveuk.com.invalid> wrote:
> In message <524dd2a9c0News03@avisoft.f9.co.uk>
>           Martin <News03@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).
> > 
> [snip]
> > 
> > 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).
> > 
> > Can anyone throw any light on why this happens? 
> > The more technical, the better! 

> Just tried this with no PROCerror but using 'DBEdit' this gives an
> ERR 2: Internal error : abort on data transfer at &03971C84

> Which with *where &03971C84

> Address &03971C84 is at offset &00005F70 in module WindowManager

Finding the module it happened in is easy, as you say.
Finding which line of the calling code caused it is not!

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

[toc] | [prev] | [next] | [standalone]

#1271

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

More simply...

TRACE TO "<Wimp$ScrapDir>.TraceLog"
TRACE ON
TRACE PROC

at the top of your code will list every line that you're executing,
and every procedure and function that is called, which narrows the
problem to the last line that was run prior to your error handler
being called - disable the error handler if you cannot see where that
instance is. In worst case, PRINT debugging is always useful.

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.

> At last I have managed to create a small program to demonstrate this. I
> know it is a stupid thing to write, but it is only to illustrate the
> error handling problem. It is...
>
>     10 : REM Abort        Gives ERL as last line of program. Why?
>     20 :
>     30 : ON ERROR PROCerror
>     40 : SYS "Wimp_Initialise",300,&4b534154,"Test abort"
>     50 : SYS "Wimp_CreateWindow",,123456789 TO h%  :REM <<error!!
>     60 : END
>     70 :
>     80 : DEF PROCerror
>     90 : DIM err% 256
>    100 : $(err%+4)= REPORT$ +" ERL="+STR$ERL +" ERR="+STR$~ERR
>    110 : SYS "Wimp_ReportError",err%
>    120 : END
>    130 :
>    140 : REM This last line is ERL!
>
> When run it gives an Data Transfer abort with ERL=140, the last line, not
> 50.

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.

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

> Can anyone throw any light on why this happens?
> The more technical, the better!

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.

The BASIC error handler uses its current executing line pointer (which
ISTR is in one of the top registers, r10, r11, or r12 - probably r12,
'cos I think r10 is its static base and r11 is a general construction
buffer) to work out where the problems lies. It checks the programs
which have been INSTALL'd, LIBRARY'd, and OVERLAY'd (as well as the
main program). Once it has found which of those buffers the line
pointer lies within it starts searching from the beginning of the code
to find the line that the problem lies on. If it is outside of all the
3 former ones it searches the main program. If it cannot find the line
pointer in the program it is left with ... the last line in the
program.

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.

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.

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

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.

--
Gerph

[toc] | [prev] | [next] | [standalone]

#1273

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. 

[toc] | [prev] | [next] | [standalone]

#1274

This is very interesting. I've witnessed this bug a few times myself.
Martin, please do report (ha!) back about your success or otherwise
with rescuing the line number from the environment error handler.

[toc] | [prev] | [next] | [standalone]

#2731

On 08 Jan, in article
<11f0a3e9-10be-4bcd-b358-b4a83f821344@j9g2000vby.googlegroups.com>,
   wpb <w.blatchley@yahoo.com> wrote:
> This is very interesting. I've witnessed this bug a few times myself.
> Martin, please do report (ha!) back about your success or otherwise
> with rescuing the line number from the environment error handler.

Just to give an update on this problem, I eventually managed to work out
how to make Basic return the correct ERL, even after an abort in external
code executed using CALL, USR, SYS, or a *command (either directly or
using OSCLI), and that code Aborts with Data Transfer, Undefined
Instruction or Instruction Fetch.

This also means that a Basic program can get control back after such an
error, rather than just ending abruptly.

The change is in Basic v1.54, currently available only as part of RISC OS
v5.19 dated after April 29th.

See https://www.riscosopen.org/forum/forums/3/topics/1511 for some
further details and any discussion.

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

[toc] | [prev] | [next] | [standalone]

#2732

In message <534e5dc229News03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> On 08 Jan, in article
> <11f0a3e9-10be-4bcd-b358-b4a83f821344@j9g2000vby.googlegroups.com>,
>    wpb <w.blatchley@yahoo.com> wrote:
>> This is very interesting. I've witnessed this bug a few times myself.
>> Martin, please do report (ha!) back about your success or otherwise
>> with rescuing the line number from the environment error handler.

> Just to give an update on this problem, I eventually managed to work out
> how to make Basic return the correct ERL, even after an abort in external
> code executed using CALL, USR, SYS, or a *command (either directly or
> using OSCLI), and that code Aborts with Data Transfer, Undefined
> Instruction or Instruction Fetch.

> This also means that a Basic program can get control back after such an
> error, rather than just ending abruptly.

> The change is in Basic v1.54, currently available only as part of RISC OS
> v5.19 dated after April 29th.

Good work there. Thanks. I see a round of updates for my computers 
will be forthcoming.

> See https://www.riscosopen.org/forum/forums/3/topics/1511 for some
> further details and any discussion.



-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web