Impression-X bug [HW / OS specific]

Hi – I have got an issue in impression that I am unable to reproduce but some users experience 100% others not at all. Some are using Aemulor – but some are OK some not.

Here is the code:
0002880C : ÿ@-é : E92D40FF : STMDB R13!,{R0-R7,R14}
00028810 : ɈΌ : E59AE08C : LDR R14,[R10,#&08C]
00028814 : ..@à : E040000E : SUB R0,R0,R14
00028818 : .p á : E1A07000 : MOV R7,R0
0002881C : ‘.Œå : E59A1090 : LDR R1,[R10,#&090]
00028820 : `U.ë : EB015560 : BL &0007DDA8
00028824 : Ô`Œå : E59A60D4 : LDR R6,[R10,#&0D4]
00028828 : .Pۈ : E0805006 : ADD R5,R0,R6
0002882C : ….Œå : E59A008C : LDR R0,[R10,#&08C]
00028830 : €.‡à : E0870080 : ADD R0,R7,R0,LSL #1
00028834 : ‘.Œå : E59A1090 : LDR R1,[R10,#&090]
00028838 : ZU.ë : EB01555A : BL &0007DDA8
0002883C : .0ۈ : E0803006 : ADD R3,R0,R6
00028840 : ..flå : E59F0004 : LDR R0,&0002884C
00028844 : ..•à : E08F0000 : ADD R0,PC,R0
00028848 : …ê : EA000000 : B &00028850
0002884C : Øãÿ. : 03FFE3D8 : MVNEQS R14,#&60000003
00028850 : ..‘å : E5900000 : LDR R0,[R0,#0]
00028854 : .. ã : E3A01E19 : MOV R1,#&0190
00028858 : RU.ë : EB015552 : BL &0007DDA8
– Get Abort on data transfer @ x28858 – code ends at x89154

Any ideas what’s wrong – is at a v7 / Aemulor issue?

I’ve got quite a few reported bugs I cant reproduce.

I have confirmed OK on Iyonix 5.16, Virtual RPC 4.39, Pi B+ 5.21
Confirmed Failures on ARMX6 & Pi B both 5.21

Thanks
Richard

Get Abort on data transfer @ x28858 – code ends at x89154
Any ideas wha’ts wrong – is at a v7 / Aemulor issue?

Doesn’t look like it’s been 32 bitted yet. By my maths when it aborts R0=0×4026C24 (you could check with *SHOWREGS) which looks like it’s trying to ADRL something at 0×26C24 but is relying on the 26 bit behaviour of wrapping the memory map at 64MB.

Presumably your WimpSlot is < 65MB, so it aborts.

relying on the 26 bit behaviour of wrapping the memory map at 64MB.

Presumably your WimpSlot is < 65MB, so it aborts.

So a reasonable diagnostic would be to set a wimpslot smaller than 64MB and test, then set a wimpslot larger than 64MB and test?
Or am I being too simplistic?

Yes this module hasn’t been 32 bited yet. Everyone should be using Aemulor on a 32bit machine. So the wrap around should be handled – does it mean it’s an Aemulor issue or is it a RO issue? Or some interaction between the two. The thing I don’t understand is why it works on some but not others – what is different?

On RO4.02
*where &4026C24
Address &04026C24 is at offset &00026C24 in dynamic area ADFS Map (Drive 4) (mapped-out page)

On RO5.19 – the address is in ROM

Yes this module hasn’t been 32 bited yet. Everyone should be using Aemulor on a 32bit machine.

I don’t think that came out quite right. It reads as everyone should have and run a copy of Aemulor.¹

I think you meant everyone using Impression on a 32 bit machine should be using Aemulor to attempt to fix the issues with 26/32 bit behaviour differences.

¹ Although that is perfectly feasible for free on some 32 bit boards many people still won’t have a copy. Obviously buying a copy to use while using a half converted Impression may appeal to some people and not to others.

Yes it did come out a but wrong – the people with issues (most of them but not all) are using 32bit machines with Aemulor (it wont load without Aemulor on a 32bit machine) another user on FP7500 on VRPC has a different abort address (still to investigate may be coincidence).

On both my dev machines it work’s perfectly – VRPC SA and Iyonix 5.16 Aemulor.

I could just mask off the top bits / fix the macro that generates this code but I want to understand what the differences are.

More information: I have confirmed failures on VRPC 6.20 and 4.02. Also Is the where command unavailable on 4.39? My VRPC knows nothing of it. I’m using V1.7.1.0 of VRPC. I’ve started looking at the other crash location and it looks different, but I can reproduce that one if I chose a FP7500 – so I’m going to add some reporter calls.

I believe the ARMClub/Druck version of ‘where’ works on all RISC OS versions. Available here

Richard, could I persuade you to use Martin Avison’s !Reporter , as this has a “Where” option in it’s menu?

I am not sure if you saw my post but it also occurred under ArcEm on my Pi B.

Edit: You might need the Where module from Druck as per Chris’ post, I can’t remember as not at the Pi!

You might need the Where module from Druck as per Chris’ post

I believe Reporter points you at loading that version to allow use of the facility.

I believe Reporter points you at loading that version to allow use of the facility.

Reporter includes code that does the equivalent of Where and ShowRegs, plus a disassembly of the code around the abort, when *ReportWhere is run.

Reporter includes code that does the equivalent of Where and ShowRegs

I stand corrected.

I have been using Martin’s excellent !Reporter to fix some other bugs my question/issue has been that this code doesn’t fail at this point on any of my machines. But I had only used it to insert debug code in the impression project to debug issues. – I will see if it can give my any more insight tonight.

Where does not know what is at address 4026c24 but using reporter data can be read from it on my machines – as the code relates to redraw area calculation on my machine it redraws a bit too much screen with data it reads. Have fixed the access. Is there a command that will dump the full riscos memory map and what it belongs too?

Is there a command that will dump the full riscos memory map and what it belongs too?

That would be nice. A lot of the memory map can be read via DynamicArea or OS_Module calls, however there are literally dozens of things that could easily be “lost” in the memory map.

The biggie, obviously, is all of the paged out tasks. I am not aware of any call (legal or otherwise) to determine where in physical memory is the workspace of a specific task. I think the Wimp manages this internally and that’s that.

Likewise, it is easy to claim workspace in the RMA, but there is no tagging performed on this. Even as a module, this just isn’t easily done. For example, !Zap can read module “workspace” by looking at the private word and seeing if it points to an OS_Heap value. Problem is, if more memory is required and is claimed, this RMA claim simply cannot be associated with the parent module. For example, my MIDI module claims memory for buffers. These are not part of the “workspace”, so are not accessible by reading the module workspace. They are in the RMA, and you might encounter them if you run OS_Heap operations on the RMA. But how to know the owner? I don’t think this is possible. The module knows where the data is. That’s all.