Not a heap block

Last night I encountered a “not a heap block” error message from Zap (1.49 – rick-07). Whilst looking through a stack of code in different files. Pi4, RISC OS 5.29 (4-Aug). However, I did note that my passively cooled Pi was very hot.

This morning I’ve gone through numerous scenarios trying to capture some debug information when I get the error message without success.

The issue emerges when I take different steps, either cycling through the files using Director or opening a group of text files dropped onto the icon bar.

The problem emerges at different time intervals depending on whether I open a task window before opening the group of files or after. So, for example, if I open a task window and then the files, I encounter the issue much earlier.

*In the meantime think I will give StrongED a whirl, although the toolbar visually irritates me, including the lack of a dark mode. ;)

This isn’t really a RISC OS bug. ;)

And, yes, Zap could do with some ¹ TLC.

I’ve come across that, and no real pattern to how it happens. Sometimes it’s perfectly happy loading the entire Wimp source in one go, other times it falls over loading a little file. <shrug>
Usually I just quit and reload.

although the toolbar visually irritates me

+1 especially the lips which reminds me of an awful song from the eighties…
Oh, and the info bar at the bottom… but there’s probably an option somewhere to turn these off.

Just looked – editor menu, BaseMode → Choices → Toolbars and untick them both.

Sadly, it looks like the bitmap font size is fixed, which makes it useless on the Pi 1. Given the 7" screen, in Zap I use a 12×24 text size for comfortable viewing.

¹ This is known as “British understatement”.

I’ve come across that, and no real pattern to how it happens. Sometimes it’s perfectly happy loading the entire Wimp source in one go, other times it falls over loading a little file.

Sounds like a bug I fixed in StrongED some time ago. Everything worked fine except when the allocation heap had exactly 0 bytes free. Took months to find as initially there was no reproducible case. As I learned more over time I was able to increase the frequency of it happening, eventually leading to a fix.

It appears that Zap has a similar edge case, and finding it may be equally hard.

although the toolbar visually irritates me

+1 especially the lips which reminds me of an awful song from the eighties…

Toolbar icons can be removed by editing a mode’s ModeFile, in this case it’s BaseMode.

Oh, and the info bar at the bottom… but there’s probably an option somewhere to

Just looked – editor menu, BaseMode → Choices → Toolbars and untick them both.

Please note that the Toolbar & Infobar as set on a per mode basis so you’ll need to turn them off in each mode that you use. You can do it for all modes at once but that requires some advanced StrongED usage. :-)

including the lack of a dark mode. ;)

StrongED does come with a dark theme. Iconbar menu, Choices → Display → Alternative colour scheme. Assuming se4.69f11 here, things work differently in se4.70a15 (the latest test release).

Sadly, it looks like the bitmap font size is fixed, which makes it useless on the Pi 1. Given the 7" screen, in Zap I use a 12×24 text size for comfortable viewing.

The test release supports different font sizes, including 12×24 (Man+?). In fact, I ported a number of fonts from ZapFonts to StrongED where permitted by licence.

StrongFont v1.08 (available from the website) can convert Zap fonts to StrongED format, it can also convert BDF fonts.

except when the allocation heap had exactly 0 bytes free.

Not a heap block – that’s an OS error, isn’t it? Maybe the OS is where the fix ought to be?

Toolbar icons can be removed by editing a mode’s ModeFile

Good to know. Thanks.

Alternative colour scheme.

I interpreted that as “the toolbar doesn’t have a dark scheme”, and indeed it remains painfully bright when the editor colours are something-on-black.

The test release supports different font sizes

Hehe, I had a feeling you’d pop up and say “actually…”. And, yes, it’s Man+Bold or something. It’s only 22 lines down the screen, but it makes a 7" monitor look like a section of a regular sized one. ;)

Thank you for your input and guidance. I’m beginning to think the issue lies with Zap’s Task window code.

Today, going with a hunch related to whether I opened a TaskWindow (Zap) first or second which seemed to impact how quickly the observed issue takes place.

In order to test that theory. I opened a directory that contained an Obey file with the debugging commands within it. I then opened a Task Window from the icon bar icon, and selected the menu item “Task window ^F12”. On the displayed Task Window I dragged and dropped the obey file onto the window; watching the commands run. I closed the task window and then re-opened it and typed *where – it displays "Address &20604574 is at offset &00000CC0 in module ‘LineEditor’.

Sadly there’s no debug file, as the computer tends to freeze, but I can Ctrl-break to restart.

Is there a problem with LineEditor?

If you’re running Reporter, you might spot a few silent errors along the way. I think these, too, were related to TaskWindow, but I was concentrating more on sending IPP bitmaps to my printer, so only sort of subconsciously noticed it flash by in the logging.

Thanks, Rick. Here’s the error posted below that occurs within the report.

18:19:08.04 | Line Editor boot file
18:19:08.04 |
18:19:08.04 RMEnsure LineEditor 0.00 X RMLoad ZapExtensions:LineEditor.LineEditor 16 2_0000011 2 0 &1000
18:19:08.04  X RMLoad ZapExtensions:LineEditor.LineEditor 16 2_0000011 2 0 &1000
18:19:08.04 RMLoad ZapExtensions:LineEditor.LineEditor 16 2_0000011 2 0 &1000
18:19:08.05 Set CLI$Prompt <17><1>*
18:19:08.05 Set LineEditor$Edit <17><2>
18:19:08.05 Set LineEditor$List <17><3>
18:19:08.05 Set LineEditor$Type <17><4>
18:19:08.05 Set LineEditor$Output <17><5>
18:19:08.05 Exec
18:19:08.05 %TaskWindow 2C603A18 00000000 
18:19:08.05 Exec
18:19:35.12 ** Error **
  Error  : &80000002
  Message: Internal error: abort on data transfer at &2061372C
18:19:35.12 Exec
Address &20613734 in Module   LineEditor          @ &20612A74 + &CC0
Register dump (at &200032B0) is:
pc  = &20613734  Flags=&00000113=nzcv if  Mode=SVC 32 bit
r0  = &200027E4 : ä'.  :  536881124 => &000001E6 : æ... : 486
r1  = &000000FF : .... :        255
r2  = &20000000 : ...  :  536870912 => &70616548 : Heap : 1885431112
r3  = &0000000C : .... :         12
r4  = &200027E4 : ä'.  :  536881124 => &000001E6 : æ... : 486
r5  = &00000000 : .... :          0
r6  = &00000000 : .... :          0
r7  = &20606474 : td`  :  543188084 => &702A010D : ..*p : 1881800973
r8  = &200040FF : .@.  :  536887551
r9  = &523F7150 : Pq?R : 1379889488
r10 = &00000400 : .... :       1024
r11 = &00000000 : .... :          0
r12 = &523F7014 : .p?R : 1379889172
r13 = &FA207F74 : t. ú : 4196433780
r14 = &20616818 : .ha  :  543254552 => &A903164D : M..© : 2835551821
Code around address is:
206136FC : E35E0002 : ..^ã : CMP     R14,#2
20613700 : 2A000007 : ...* : BCS     &20613724
20613704 : E3100010 : ...ã : TST     R0,#&10            ; =16
20613708 : 13800004 : ..€. : ORRNE   R0,R0,#4
2061370C : E3100020 :  ..ã : TST     R0,#&20            ; =" "
20613710 : E3C000F0 : ð.Àã : BIC     R0,R0,#&F0         ; ="ð"
20613714 : 13800010 : ..€. : ORRNE   R0,R0,#&10         ; =16
20613718 : E3800068 : h.ۋ : ORR     R0,R0,#&68         ; ="h"
2061371C : E331007E : ~.1ã : TEQ     R1,#&7E            ; ="~"
20613720 : 02800002 : ..€. : ADDEQ   R0,R0,#2
20613724 : E28FEA03 : .ê•â : ADR     R14,&2061672C
20613728 : E28EE0EC : ìà‰â : ADD     R14,R14,#&EC       ; ="ì"
2061372C > E7DE1000 > ..Þç : LDRB    R1,[R14,R0]
20613730 : E1A00004 : .. á : MOV     R0,R4
20613734 : E24FED0B : .íOâ : ADR     R14,&2061347C
20613738 : E08FF101 : .ñ•à : ADD     PC,PC,R1,LSL #2

Reporter 2.74 (01 Aug 2021)     Listed 307 lines>

EDIT: Thank you, Martin, for the tip below. I have updated the report above; it reveals the error occurs when I click on the close icon of the Task Window (Zap)

@Andrew: Note that it is best to use the Where from the Reporter menu after an abort, as it will also report the code round the error (with the module if within one), and the registers at the time of the error.

On further investigation, I reverted to RISC OS 5.28(16-Dec-20). The issue now appears to be an edge case, only surfacing when loading twelve files simultaneously or clicking through the files numerous times using Director.

Thanks, Martin. !Reporter is an impressive utility.

Not a heap block – that’s an OS error, isn’t it? Maybe the OS is where the fix ought to be?

Yes, it’s an OS error. However it may still be caused by Zap if it’s overrunning a heap block resulting in the guard word of the next heap block being corrupted. When that block is then accessed the ‘Not a heap block’ error will be raised.

I interpreted that as “the toolbar doesn’t have a dark scheme”, and indeed it remains painfully bright when the editor colours are something-on-black.

True, but it’s just a template and sprites so it’d be easy for anyone to create a dark toolbar scheme. A lot of work though if one wants to do this for all modes.

Had a play with putting an icon on the toolbar to act as configurable background but it didn’t work. The icons for the buttons (plotted using Wimp_PlotIcon) are plotted underneath the background icon. So, this needs some more thinking about.

However it may still be caused by Zap if it’s overrunning a heap block resulting in the guard word of the next heap block being corrupted.

I thought that the ‘Not a Heap Block’ error was raised when the block pointer passed to Free or Extend was not on the chain of allocated blocks? This can either be because the pointer used is duff, or the heap itself has been corrupted (eg by an overrun) so that the block chain cannot be followed. Heap blocks themselves do not have a guard word.

To quickly validate a heap header plus the allocated and free chains, you can use *ReportHeap xxx where xxx is the address of an OS Heap. If an error is found it is listed with debug info. Blocks can also be listed.

Get this with StrongEd’s Taskwindows too. Open a Taskwindow and then close it to trigger the abort.
Reporter reports:
Error : &80000002
Message: Internal error: abort on data transfer at &204B5F0C

The register dump is the same apart from R0 pointing to a different address in the RMA (&20002A44)

Have now had a look at this and the data abort is being caused by the XOS_ReadC in line 939 returning with V set when the TaskWindow is closed, which isn’t being handled, and so the code goes on its merry way with duff values in the registers until it hits the LDR in line 1144.
Have submitted a fix to add:
ORRVS R8,R8,#fEsc%
BVS leaveedit
which causes the code to exit pretending that the Escape key has been pressed, which seemed a sensible exit strategy.
The module will then get a Service_WimpCloseDown and tidy up the buffers.

LineEditor 2.77 is now available from https://github.com/philpem/LineEditor
At the moment the CI Build process is broken so you’ll need to download the files and build it yourself in order to create the module.

CI build is now fixed and build.riscos.online redeployed with the new OS; the job just needs kicking off again.

Thanks to Phil Pemberton for reporting the problem.

It turned out to be a rare case of allocations that were made through OS_Heap where the space left at the end of the heap was the same as the allocation size, and the allocation size was a multiple of the page size. There was a secondary bug behind it where the allocation size checks were close to the remaining size. Regression tests for this sort of allocation of the heap and DA Heaps, so it shouldn’t happen again.

@Richard. Thank you for the fix and for informing us that the issue affected more than one program.

I built LineEditor and it has made my RasPi stable again. It used to freeze after I closed a TaskWindow.

Does it form part of a distribution of Zap now? If not, shouldn’t it?

Edit: and of course I forgot, thanks to those who found and fixed the problem.