Not a heap block
Andrew McCarthy (3688) 601 posts |
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. ;) |
Rick Murray (539) 13747 posts |
This isn’t really a RISC OS bug. ;) And, yes, Zap could do with some 1 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>
+1 especially the lips which reminds me of an awful song from the eighties… 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. 1 This is known as “British understatement”. |
Fred Graute (114) 639 posts |
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 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 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. :-)
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).
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. |
Rick Murray (539) 13747 posts |
Not a heap block – that’s an OS error, isn’t it? Maybe the OS is where the fix ought to be?
Good to know. Thanks.
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.
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. ;) |
Andrew McCarthy (3688) 601 posts |
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? |
Rick Murray (539) 13747 posts |
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. |
Andrew McCarthy (3688) 601 posts |
Thanks, Rick. Here’s the error posted below that occurs within the report.
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) |
Martin Avison (27) 1479 posts |
@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. |
Andrew McCarthy (3688) 601 posts |
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. |
Fred Graute (114) 639 posts |
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.
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. |
Martin Avison (27) 1479 posts |
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 |
Richard Coleman (3190) 54 posts |
Get this with StrongEd’s Taskwindows too. Open a Taskwindow and then close it to trigger the abort. The register dump is the same apart from R0 pointing to a different address in the RMA (&20002A44) |
Richard Coleman (3190) 54 posts |
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. |
Richard Coleman (3190) 54 posts |
LineEditor 2.77 is now available from https://github.com/philpem/LineEditor |
Charles Ferguson (8243) 427 posts |
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. |
Andrew McCarthy (3688) 601 posts |
@Richard. Thank you for the fix and for informing us that the issue affected more than one program. |
Dave Higton (1515) 3477 posts |
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. |