System heap memory leakage (OS_FSControl,37)

Apologies for the length.

ARMini RISC OS 5.18 stable and 5.19 (2 Apr 2012) used in the tests, although problem was observed before 5.18 was released.

For a while now a number of ARMini users have been experiencing ‘random’ crashes, which often occurred overnight or at other times when the machine was unattended and ‘idling’. When the initial error box had been cleared, the machine needed a reboot, because most subsequent actions resulted in further errors due to a lack of system (not total) memory. Whenever the error occurred, the machine had been running for several days.

The immediate problem was traced to the system heap reaching its limit of 4MB. Further investigation showed that the system heap, which started at about 200KB, was growing almost linearly at about 40KB an hour. Thus the 4MB limit would be reached in about 4 days.

The standard ARMini runs a small app (NewIcons) at boot, which ‘manages’ the scsi disc icons on the iconbar, by installing custom icons for the drives (the ARMini has a memory stick for the boot drive (scsi::0) and an inbuilt 2-slot card reader (scsi::1 and scsi::2)), and using the drive name for the text under the icon. It was this app that the problem could be traced back to.

In operation, NewIcons calls pollidle with a timeout of 5 sec. When it receives a poll null event, it iterates through the iconbar icons looking for those owned by SCSI Filer. When it finds one it attempts to find the drive/disc name by asking the OS to canonicalise the appropriate string SCSI::N.$, where N is 0 – 2. This is where the problem arises. It calls the X form of the SWI OS_FSControl with R0 = 37 and R1 pointing to the string to be expanded. It then checks the flags returned and if bit 0 is clear, it extracts the disc name from the returned string and if necessary sets the icon text if it has changed. If bit 0 is set, then it simply sets the icon text to :0, :1 or :2 as needed.

In normal use, drive 0 is the boot drive, named ‘ARMini’, but the card reader is usually empty, so drives 1 and 2 both return errors (The error would actually be ‘The disc drive is empty’). It appears that when SYS"XOS_FSControl",37 returns an error, it doesn’t free any temporary memory it has claimed in the system heap, which is where the memory leak is coming from.

The evidence:
1. When both card slots are populated the leak does not occur

2. If the code of NewIcons is modified so it only looks for drive 0 there is no memory leak

3. If the contents of the system heap is *saved to disc then there are large parts containing thousands of text fragments SCSI::1.$ and SCSI::2.$ separated by a few nulls and other odd bytes. For example, I left my machine running over last night from a reboot. The system heap started at 164KB after my core apps were run. Late this morning when checked, the system heap was at 1020 KB. Dumping this to file, there was a contiguous block within it of near 800KB containing little more than the text fragments SCSI::1.$ and SCSI::2.$. There was no evidence of any SCSI::0.$ or SCSI::ARMini.S anywhere.

4. Even on the Iyonix, running a small test prgram that attempts to canonicalise hundreds of ‘non-existent’ strings of similar format causes the system heap to increase substantially.

The questions are: Is this a bug that has never been noticed before? Do similar memory leaks occur when other SWIs produce an error, or is it particular to OS_FSControl?

The questions are: Is this a bug that has never been noticed before?

Looks like it! If I do

REPEAT
SYS"XOS_FSControl",37,“adfs::5.n*t.there?”,buffer,0,0,256
UNTIL FALSE

I should point out that SCSIFS_MiscOp 1 would probably have been a simpler way to find out if the media had changed.

Are you looking into it Sprow? I’m in the middle of testing a fix now.

Easily fixed.

Thanks for that.

I should point out that SCSIFS_MiscOp 1 would probably have been a simpler way to find out if the media had changed.

Well, Andrew R is around here regularly, so I guess he can pass that on to the programmer.

I’ve checked in a fix. It was a fairly commonly used routine in FileSwitch which was failing to free the memory, so it’s possible a few other SWIs could have been leaking memory as well.

Are you looking into it Sprow? I’m in the middle of testing a fix now.

Be my guest – having confirmed it I’d only got as far as loading the source code and wondering whether TopPath_DoBusinessToPath should free on error or whether it was the OS_FSControl’s SwiExit VS that was wrong.

Let’s not squabble over bugs, there are plenty to go around!

Let’s not squabble over bugs, there are plenty to go around!

Indeed!

It looks like this bug was the cause of the systeam heap filling that was reported a while ago if a machine is indefinitely left waiting at the “waiting for boot drive to be ready” prompt.

I have installed the latest ROM on the ARMini, and have now had NewIcons running for a few hours without any evidence for any system heap leakage, so it certainly looks as if this problem is done and dusted.

Thanks Jeffrey.