Re: [StrongED] StrongHelp 2.87 available

[Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx>]

The following bytes were arranged on 4 Sep 2012 by Fred Graute :

> In message <3fa5ffc952.martin@xxxxxxxxxxxxxxxx>
>           Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx> wrote:
>
> > The following bytes were arranged on 4 Sep 2012 by Fred Graute :
> >

> > > What happens when you do the same with StrongHelp 2.86?
> >
> > The same crash.
>
> And pressing F1? (Assuming that has HelpWord tied to it.)

Same again.

> The manual that opens is the StrongHelp manual. What happens if you open
> this from StrongHelp's 'About this program' box?

Does that really happen if you press F1 on an empty document?  The
button in the info box works as expected.

> Thanks for the address info Martin. Could you please rerun the test and
> include the output from *ShowRegs (should asked for this straight way).

From a base of &2050C1B4, abort on data transfer at &20515502 (same
offset as last time).  *ShowRegs gives:

Register dump (stored at &2000AE30) is:
R0  = 00000014 R1  = 2032D934 R2  = 00000054 R3  = 0CA038EC
R4  = 00000000 R5  = 0000005A R6  = 0000ADC8 R7  = 00000000
R8  = 2032D934 R9  = 2032C4FB R10 = FFFFFFFF R11 = 0000A038
R12 = 2032C25C R13 = 2032D8F8 R14 = 00000000 R15 = 20515502
Mode USR32 flags set: nzcvqjggggEAifT        PSR = 00000330

As I suspected, the PSR's Thumb bit (5) is set!

I get a crash at a different offset if I use HelpWord with the cursor at
the end of a line (which normally opens the 'this is a line feed' page):

Register dump (stored at &2000AE30) is:
R0  = D0B20000 R1  = 202B9A54 R2  = 00000054 R3  = 0CA038EC
R4  = 08000004 R5  = 00000000 R6  = D0B20000 R7  = 0000B2D0
R8  = 202B9A54 R9  = 202B861B R10 = FFFFFFFF R11 = 0000A038
R12 = 202B837C R13 = 202B99E0 R14 = 2051499C R15 = 20513FEC
Mode USR32 flags set: NzCvqjggggEAift        PSR = A0000310

The instruction was "LDRNE R0,[R0,#0]" (note bit 5 isn't set this time).
This is a very unpredictable sort of bug.

> The address at which the abort occurs is inside the code that reads the
> '!Configuration' file and I can't anything obviously wrong with it.

It probably ended up there by accident.  I doubt the configuration file
is the problem.

> The register dump might provide a clue like which register holds the
> address used in the aborted memory transfer.

As I don't have a Thumb disassembler, I can't tell you which register it
thought it was using in whatever garbage instruction it accidentally
decoded.  All I can suggest is that you trace through the code path
you'd expect HelpWord to take and make sure you're not doing anything
naughty.

NB: A known (but not very well publicised) problem with the BeagleBoard
is that the Iyonix CPU actually contained some bugs which are only now
coming to light.  Certain instructions which were made illegal in the
switch to 32-bit, such as MOVS PC,R14, were working when they shouldn't
have.  Therefore, some programmers thought their code was 32-bit
compatible when it was technically nothing of the sort.  Hand-written
assembler is particularly prone.

The OMAP is only the second non-26-bit processor RISC OS has ever run
on, thus demonstrating the importance of multiple test cases.

-- 
  __<^>__
 / _   _ \  I don't have a problem with God; it's his fan club I can't stand.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

-- 
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx