Zero pain in Zap during undo

Time: Fri Sep 7 07:43:12 2018
Location: Offset 00034b24 in module Zap
Current Wimp task: Zap
Last app to start: WindowManager Run Fat32fs::Fatty.$.Compiler.Apps.DDE.Boot

R0 = ffffffff R1 = 00000017 R2 = 00000001 R3 = 00000000
R4 = 00000000 R5 = 00000000 R6 = 00014758 R7 = 0000c464
R8 = 00000000 R9 = 00000000 R10 = 00000000 R11 = 2031b9b4
R12 = 2031b9b4 R13 = 0000871c R14 = 20481e8c R15 = 20481ea0
DFAR = 0000006c Mode USR32 Flags nZCv if PSR = 60000110

20481e58 : e59c72ac : LDR R7,[R12,#684]
20481e5c : e5b760a0 : LDR R6,[R7,#160]!
20481e60 : e59a400c : LDR R4,[R10,#12]
20481e64 : e1a00004 : MOV R0,R4
20481e68 : ebffafc3 : BL &2046DD7C
20481e6c : 71a03000 : MOVVC R3,R0
20481e70 : 7b00001c : BLVC &20481EE8
20481e74 : e49df004 : LDR PC,[R13],#4
20481e78 : e92d47ff : STMDB R13!,{R0-R10,R14}
20481e7c : e1a0a008 : MOV R10,R8
20481e80 : e59c72ac : LDR R7,[R12,#684]
20481e84 : e5b760a0 : LDR R6,[R7,#160]!
20481e88 : ebff3b79 : BL &20450C74
20481e8c : 6a000013 : BVS &20481EE0
20481e90 : e158000a : CMP R8,R10
20481e94 : 18bd87ff : LDMNEIA R13!,{R0-R10,PC}
20481e98 * e599006c * LDR R0,[R9,#108]
20481e9c : e3300000 : TEQ R0,#0
20481ea0 : 18bd87ff : LDMNEIA R13!,{R0-R10,PC}
20481ea4 : e59ca1d4 : LDR R10,[R12,#468]
20481ea8 : e59c1108 : LDR R1,[R12,#264]
20481eac : e5970008 : LDR R0,[R7,#8]
20481eb0 : e5810000 : STR R0,[R1,#0]
20481eb4 : ef0600cb : SWI XWimp_GetWindowState
20481eb8 : 6a000008 : BVS &20481EE0
20481ebc : e591e020 : LDR R14,[R1,#32]
20481ec0 : e31e0801 : TST R14,#&00010000
20481ec4 : 08bd87ff : LDMEQIA R13!,{R0-R10,PC}
20481ec8 : e59a400c : LDR R4,[R10,#12]
20481ecc : e59a3004 : LDR R3,[R10,#4]
20481ed0 : e1a00003 : MOV R0,R3
20481ed4 : ebffaf98 : BL &2046DD3C

R15 = 20481ea0 = Zap +34b2c = fill_words +ea4
R14_usr = 20481e8c = Zap +34b18 = fill_words +e90
Function call to 20450c74 = Zap +3900 = conv_index_offs +0

USR stack:
0000871c : ffffffff : – R0
00008720 : 00000017 : | R1
00008724 : 00000001 : | R2
00008728 : 00000000 : | R3
0000872c : 00000000 : | R4
00008730 : 00000000 : | R5
00008734 : 000028dc : | R6
00008738 : 000401ec : | R7
0000873c : 00000000 : | R8
00008740 : 0003c124 : | R9
00008744 : a0002624 : | R10
00008748 : 2045a2a4 : | R14: 2045a2a4 (ASM call to 20481e78)
: : | 2045a2a4 = Zap +cf30
: : | = stop_operation +74
: : | 20481e78 = Zap +34b04
: : | = fill_words +e7c
0000874c : 00000000 : – R10
00008750 : 2031b9b4 : | R11
00008754 : 20475f00 : | R14: 20475f00 (ASM call to 2045ad3c)
: : | 20475f00 = Zap +28b8c
: : | = undo_command +12c
: : | 2045ad3c = Zap +d9c8
: : | = undo_stop_operation +0

It seems that calls to conv_index_offs often forget to check if the returned R8 and R9 against 0

What sequence of actions causes this to happen?

What sequence of actions causes this to happen?

What version of Zap is André using? It might be something you fixed in the version you’ve amended if it isn’t your amended version he’s using.

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

;-)

I’m not aware of a bug during undo, or having fixed such a thing…And I used undo a lot over the weekend…

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

;-)

“It doesn’t work.” summarises a job logged yesterday. The job notes that a system can’t communicate with a manufacturers support system. Could the firewall be blocking it?
Missing information? The URL/IP of the target, the system name/IP of the source, the TCP / UDP port in use and whether or not they were trying to communicate direct or via the proxy server (if they were using http/https)

From that have you any ideas what it could be yet?

Steve,

From that have you any ideas what it could be yet?

How many years have you been in IT support and you don’t know the answer?

Of course it is you at fault for not sorting it or knowing how to fix it as they have given you enough information , so what the problkem or do they have to get someone who knows what they are doing to sort it :-)

Aah, Forum issues stike again

How many years have you been in IT support and you don’t know the answer?

Long enough to know the habits of certain users¹ and to hazard a guess that they were using http/https and not setting ALL the proxy details. :) That despite my regular claim²
I asked a question and got some clarification from the manufacturers support because they were in the circulation (he told what should be set) the user has of course gone silent.

Back on thread, I’m assuming André will answer the question “What version of Zap is André using?” shortly.

¹ Fail to supply relevant details in the first place and dismiss the request for specifics with a statement that they already logged a job. Oh and include higher management in the email chain to stir things up.
²“Look I’m psychotic not psychic, and I may kill anyone who disagrees” :)

There is a:-
In Ricks version 03

bl &39ac (proc ’conv_index_offs)
since the Z flag is set
next instruction
ldr r0,[r9,#108] r9= 0 so is 108 special?

proc ‘conv_index_offs’

&39ac
code
&39cc movmi r9,#0
code
mov pc,r14

What sequence of actions causes this to happen?

Well, if I knew the sequence I would have mentionned, playing with Undo/Redo while coding makes it a little hard to reproduce.

What version of Zap is André using?

I thought I upgraded to Rick’s version, but no I am still using the tim01 version. The code concerned by the ZeroPain was not rouched though. See cw_Goto_update_update in s.boxes (corresponds to fill_words +ea4), there is a call to conv_index_offs which returns pointers in R8 & R9 but these pointers may have a value of 0 and cw_Goto_update_update doesn’t check this.

Note that cw_Goto_update_update is not the only place where R8/R9 are not checked before use after a call to conv_index_offs.

Off topic, while updating the old BASIC code in Boufy which redefines part of the system font, I thought of using the system font in !Zap to visualise the level maps in the source code but I had redraw issues as if the lines had the wrong height. Has anyone redraw issues with the system font?

ldr r0,[r9,#108] r9= 0 so is 108 special?

No. 108 is &6C, which is in the area reserved for FIQ code (reference).

I don’t think 108 is special, I think it’s a test that failed (that would be your movmi) that probably should have caused the function to exit, not carry on with a bogus pointer…

I think Jef – did a file which showed which zeropage offsets could be replaced by a call – can’t remember what it was called :-( anyone remember?

With ref to Andre – With the VRPC-DL and !Zap – am back to using a older version of ZapRedraw 0.48 (20 Aug 2005).
With ref the two later version – cause some strange effect.

Can some of the updates to modules – use numbering like:-

(if a major number change is deemed in-appropate)

vsn 1.7500 – 1.7599

With the VRPC-DL and !Zap – am back to using a older version of ZapRedraw 0.48 (20 Aug 2005).

FWIW I use the last 26bit build of Zap on my 26bit platforms, VRPC’s and RPCEmu’s, from here This includes :-

*help zapredraw
==> Help on keyword ZapRedraw
Module is: ZapRedraw       0.39 (06 Nov 2002) � Zap Developers

As I understand it that 26bit build was a high watermark, the later official 32bit builds were betas, or work in progress, or worked (mostly) on the Iyonix. So far I have seen no good reason to attempt to use any current 32bit build on my 26bit platforms, but to be fair Rick’s latest, rick-04, looks good on the Titanium and RPi3B+, he said as a StrongED user that is.

Back to the topic, with Zap 1.48 rick-04, undo is entirely painless here, so far.

HTH.

P.S. I did make the assumption that VRPC-DL is OS4.02.

Back to the topic, with Zap 1.48 rick-04, undo is entirely painless here, so far.

That’s why I wanted to know what André was doing to trigger the problem. There seems to be something as noted above, so there may be some edge case that triggers this that the most of us don’t see…

André – just a quick question: what mode were you using? Text?

Has anyone redraw issues with the system font?

Yes, it’s something I’d seen before. Draw a window over a text in system font and the lines jump up and down.

After a bit of digging around I found the problem in ZapRedraw. There is a patch by Tank in s.VDURedraw where the first instruction reads:

this needs to be:

Otherwise it reads from the wrong word in the redraw structure.

André – just a quick question: what mode were you using? Text?

I was using C. I also notice from time to time when you play to much with undo and redo that it becomes inacurate, but once again since it involves changes scatered through the file and more than a single use of undo/redo during the edition, I fell like I could try all day and not be able to reproduce the problem.

ADD R10,R10,#2

The good news is that the not entirely correct ADD R10,R10,#4 only occurs once in the ZapRedraw module and can be edited with StrongED. That worked here.

More good news is that this is an easy ROOL Tools build using rick’s source.

Thanks all round.

Thanks Fred – Trying ZapRedrew 0.49 again – or is that 0.491 :-)

With VRPC-DL using one ‘HostFS’ for both ro5.25/ro4.02 – so try to have one version of Zap & others progs on call :-)

I had a little bit time to get the rick-04 sources and make a few little updates , mainly to ZapRedraw (ensuring correct use of r_linesp (contains line spacing in the bottom 2 bytes and char spacing in the top 2) and correct display of system font under various eigen factors.

Edit: link fixed

Thanks André. I’ll roll these updates into a rick-05 Real Soon Now™.

André, the link points to the old ZapSource148tim01/zip release, not the new ZapSource148tim02/zip.

Thanks André. I’ll roll these updates into a rick-05 Real Soon Now™.

When you have done so, please please upload the latest version to !Store as the latest version there is still 1.48.7.

Okay. I’ll send an email to RComp if I can take over Zap to get it updated.

Opening a Cmhg containing a large help text shows some issues. The file is opened in Assmbleur mode with autowidth on and displays incorrectly because some lines exceeds the width of 255 chars.

Autowidth should be limited to 255 chars for assembler. It wouldn’t surprise me if other modes have similar issues.

An update patch is now available to bring Zap up to “rick-05”. This should be applied to a previous (rick-04) installation.
It is NOT a full release. I’ll get to that soon, and hopefully get it up on !Store.

http://heyrick.ddns.net/files/zap-rick05.zip (~154K)

Updates Zap and ZapRedraw with André’s modifications. ZapRedraw module has been bumped to v0.50 and Zap itself has been bumped to v1.49.

Just given a quick test, and the font options all look as expected (except anti-aliased DSA doesn’t seem to handle high-bit-set ASCII – weird…).