!WinED crashes under Beta ROM

Hello

I have a problem is with WinED running on Openpandora under the development ROM (version 5.23, 22/05/2017).
When trying to create a new window, I got the following message:
“WinEd may have gone wrong. Click Continue to try to resume or Quit to stop WinEd.”
When I select Describe, I get the following message:
“Internal error: abort on data transfer at &00012F84”.

Postmortem:
12f7c in function Menu_Show
195dc in function WinEd_CreateMenu
2c574 in function ^create_clicked
20f64 in function ^DispatchIconEvents
213a4 in function Event_Process
c940 in function main
Arg2: 0×0000c8ac 51372 → …
Arg1: 0×0003e6cc 255692 → …

Under version 5.22, no problem…

Regards

François

Two questions, the answers will help other people in the diagnosis:

1. What version of WinEd? v3.20.0 is the most recent
2. Do you have zeropain installed on the 5.23 install?

Sadly WinEd has issues on modern systems. I keep meaning to look into the problems that I’m aware of, but sadly it’s just one thing on a very long to-do list… :-(

Turning the toolbars off makes things more stable IME. It still ZeroPains a lot, however.

Does anyone know if Adam is still around and supporting WinEd?

Turning the toolbars off makes things more stable IME. It still ZeroPains a lot, however.

Your statement that " it zeropains a lot" in conjunction with the earlier information from François that it gives “Internal error: abort on data transfer” suggests that the zeropain installation hasn’t been done on the 5.23 install.

François: Zeropain is not an optional install on 5.23, it is required.
When you get entries produced in the zeropain log they can be submitted to the software maintainer.

Dear all

Thank you for your answers. Indeed, !zeropain is not installed on my system. I was not aware of its existance until right now.
I will install it and let you know if it solved my issue.

Regards

François

EDIT: just install !zeropain and the issue is now solved. Thank you to all of you for your help.

François

Just a question… I just read the following article https://www.riscosopen.org/news/articles/2015/07/05/important-software-compatibility-notice.
It is said that all zer page attempts are recorded to a log to be sent to the developper. Where can I find this log?

Thank you in advanced

François

François: Zeropain is not an optional install on 5.23, it is required.

I don’t think zeropain is required. I’ve not been using it for at least 9 months after the apps in daily use had their bugs fixed, and not the ones I added to the hall of shame. Happy to add wined to that page if that is confirmed as a zeropain.

Where can I find this log?

The readme provided with zeropain tells you where the default log location in, 3rd sentence

I don’t think zeropain is required. I’ve not been using it for at least 9 months after the apps in daily use had their bugs fixed, and not the ones I added to the hall of shame.

I don’t need house insurance, my house has never burned down.
I don’t need air-bags in the car, no one has smacked into the front of it with another car.

I don’t need house insurance, my house has never burned down.
I don’t need air-bags in the car, no one has smacked into the front of it with another car.

I’m not sure that they’re comparable things, really. It’s quite possible to run a system without ZeroPain, so long as you don’t want to run software that reads from zero page. ZeroPain just let’s you also run the buggy stuff as well… And debug it, of course.

Your statement that " it zeropains a lot" in conjunction with the earlier information from François that it gives “Internal error: abort on data transfer” suggests that the zeropain installation hasn’t been done on the 5.23 install.

As far as I know, it does both on modern hardware. There are zero page reads, but also aborts even with ZeroPain installed.

IIRC, turning the toolbars off helps stabilise things quite a bit.

It’s quite possible to run a system without ZeroPain, so long as you don’t want to run software that reads from zero page.

True, but then you’d be missing the point of the hyperbole.

When your software is working correctly, ZeroPain shouldn’t do anything…at all. So having it sitting in the background shouldn’t be a cause for concern. It’s like a spare tyre, there if you need it but pretty much forgotten about otherwise.

And debug it, of course.

…or (to avoid scaring anybody off!) provide a nice ridiculously over-detailled log file to the person maintaining the application that is misbehaving to they can debug it. ;-)

There are zero page reads, but also aborts even with ZeroPain installed.

Wow. That sounds really broken. Does ZeroPain trap everything between &0 and &3FFF, or does it only trap the first few words (oflaoflaoflaofla) and various known addresses such as MetroGnome? Maybe the code is hitting an address that is not trapped?
It might be also worth looking at the code and registers at the exception point to see whether or not the eventual address is word aligned. If it isn’t, that could trigger an exception on most contemporary RISC OS machines.

True, but then you’d be missing the point of the hyperbole

Moi? do that?

It might be also worth looking at the code and registers at the exception point to see whether or not the eventual address is word aligned.

about a hundred lines of assembler and a raft of C that probably compiles nicely with a modern compiler.

It might be also worth looking at the code and registers at the exception point to see whether or not the eventual address is word aligned.

about a hundred lines of assembler and a raft of C that probably compiles nicely with a modern compiler.

:-)

Actually, a crash due to alignment errors probably won’t turn up in ZeroPain’s log as… it’s not Zero Pain. It’s Wonky Word Pain.

So, the bad news (maybe). It’s not in the ZP log.

The good news. It’s not so hard to track down.

Don’t be put off by the wall of text that follows. I’m describing in great detail on the basis of somebody who doesn’t read ARM code for fun. The entire process, after a little bit of practice/experience, takes maybe twenty seconds.

Really. :-)

Here’s a test program:

DIM code% 31
P% = code%
[ OPT 2
  MOV R0, #&8000
  ADD R0, R0, #123
  LDR R1, [R0]
  MOV PC, R14
]
CALL code%

That program tries to load a word from the address &807B. Which is not word aligned.

Running it on a modern machine (other than an early Pi in ARMv5 mode or any with alignment faults disabled) will throw up an error Application may have gone wrong. Click Continue to try to resume or Quit to stop Application.
If you click on “Describe”, it will say Internal error: abort on data transfer at &00008FC4.

Aside: Seems strange to me that the Describe message has no Continue/Quit option. So it looks like your options are: Plough on regardless, Quit, or Quit but be informed why. Hmmm…

Anyway. There’s the important thing right there. That address. &8FC4.

Now, if you are dealing with a singletasking program like my example, just go to the command line and run it.
If you are dealing with a multitasking program, things are more complicated. You cannot open a TaskWindow and look at the exception address, as it needs to be the exception address belonging to the program that failed.

There is a cheat.
Upon the application’s !Run file. The final line ought be a line that runs the !RunImage, the program proper.
After that, insert a line that says:

ShellCLI

Then run the program again, get it to crash again. Check the crash address, make sure it is the same (should be, but check).

Okay. You’ll notice the desktop has stopped and the command line has appeared at the bottom, old-school way.

Now the fun can begin.

First, subtract 16 from the exception address. The easy way is to just make the second digit from the right one less. In the case of &8FC4, the digit in question is ‘C’, so make it ‘B’. If it was an ‘A’, it would become an ‘9’.
‘0’ rolls back to ‘F’, but you also need to make the third-from-the-right digit one less.
Some examples: 8FC4 → 8FB4, 88A0 → 8890, 8800 → 87F0.

Now you have a new address pointing a little before the point where the program blew up, let’s see what’s there.

*MemoryI 8FB4 +14

This will show you some code, which will look vaguely like:

00008FB4 : .. ã : E3A00902 : MOV     R0,#&8000
00008FB8 : {.ۉ : E280007B : ADD     R0,R0,#&7B         ; ="{"
00008FBC : ..‘å : E5901000 : LDR     R1,[R0,#0]
00008FC0 : .ð á : E1A0F00E : MOV     PC,R14
00008FC4 < .... : 00000000 : ANDEQ   R0,R0,R0

Do you see the little ‘<’ marker following the address of the last instruction there? Well, that indicates the point where the program failed.

For boring technical reasons to do with the gerbils on their treadmills that make your processor work, the actual instruction that failed is two before the indicated point of failure.

Therefore, in this case, it is this that failed:

00008FBC : ..‘å : E5901000 : LDR     R1,[R0,#0]

Now, you don’t need to understand the code. You just need to know that there are two types of load and store, and what they look like.

The first is a multiple load and store. They begin LDM or STM and may have some other gibberish after. LDMEQIA is an LDM. Don’t worry what the EQIA stuff means. The format of an LDM or STM is as follows:

LDM<blah>  <pointer>, {<what to write>}

That is to say, there will be a register provided (very good chance it’ll be R13). This is often followed by an exclamation mark. Then there will be one or more different registers given in curly braces. Like this:

LDMFD  R13!, {R0-R3, R14}

The thing we need to recognise is the first register. That’s our memory pointer. LDM and STM cannot deal with unaligned addresses. They never could, but that doesn’t mean a calculated address isn’t faulty, so this could happen… Unlikely, but it could.

The other type of instruction is a single register read or write. STR or LDR. In this, the format is different. It is like:

LDR<blah>  <value to use>, [<address>, <offset>]

In this case, the value that is written or read into is provided first, and the address calculation follows in square brackets.

In it’s simplest form, the address will appear as [Rx,#0] which means Rx is our pointer register. If the # value is anything else, the pointer is Rx plus whatever the # value is.
The next version is [Rx,Ry], which means the eventual address is Rx plus Ry.
Another version that you might run into is [Rx, Ry, LSL#2] which means the effective address is Rx plus Ry-multiplied-by-4.
If you hit something that looks complicated, don’t be afraid to ask.

Now for the big reveal. By one way or another, we have determined our register(s) that provide the address. So let’s see what the registers are:

*ShowRegs

That’s the instruction you need now. Something to show you the registers as they were at the time the exception happened.

The result will be a scary looking pile of gibberish, something like this:

Register dump (stored at &20009E50) is:
R0  = 0000807B R1  = 00FFFFFF R2  = 00FFFFFF R3  = 00FFFFFF
R4  = 00FFFFFF R5  = 00FFFFFF R6  = 00FFFFFF R7  = 00FFFFFF
R8  = 00008700 R9  = 00407FD8 R10 = 00000000 R11 = 00008100
R12 = 00008F9D R13 = 00407FC0 R14 = FC1B07D0 R15 = 00008FC4
Mode USR32 flags set: nzCvqjggggeAift        PSR = 20000110

The good news is, most of that is not important.

What is important is our address. What did we do and where did we do it?

The faulty instruction was:

00008FBC : ..‘å : E5901000 : LDR     R1,[R0,#0]

This means load R1 with the word stored at address R0. It’s a simple one, no offsets or calculations required.

R0. That’s our address pointer.

What is R0? 0000807B

A hex value divisible by four should end in 0, 4, 8, or C. As this number ends with a B, it is not divisible by four. As such, it is not a word aligned address. As such, the instruction was doomed to cataclysmic failure.

[well, we gotta sex it up a little as a mere “pffft! gibberish exception message” is not exciting, it’s somewhere between mildly and extremely annoying, depending on how much data you just lost…]

If it’s your program, you’ll have the fun of working out why it just borked. If it’s somebody else’s program, you can now provide them with detailed information of what happened – alignment failure, tried to LDM from the address 807B in the instruction at 8FBC. Armed with that and a list of steps that make the program go bang, it stands a good chance of getting fixed if the developer is still interested.
Because, trust me, a “it crashed, just died on me” type report will be ignored.

There. That wasn’t so hard, was it? :-P

PS: If you stuck “ShellCLI” into your crashy app’s !Run file, don’t forget to remove it when you’re done!

Now you have a new address pointing a little before the point where the program blew up, let’s see what’s there.
*MemoryI 8FA4 +14

Should this be 8FB4? If not, please explain why not :)

Yup. Corrected. Well spotted!