No free memory in module area

I’m running RO 5.28 on a pi3B. I have one program running, and until reently it’s been running for several months without a stop or machine restart. Now however, after a few hours it quite, and any attempt to do anything, such as open a menu or a filer window gets a message similar to “no free memory in module area”, of “insufficuent memory to open menu”.

When the computer starts up, before running my program, the memory display shows the module area has 47K free, and largest block 27K. This seems a bit low.

So the two questions are: why is this happening? and how do I increase the initial module area size on restart? I can drag the slider to increase it, but that’s a manual action.

any attempt to do anything, such as open a menu or a filer window gets a message similar to “no free memory in module area”, of “insufficuent memory to open menu”.

This sounds like you’ve run out of free memory altogether, rather than it just being a problem with the module area on its own.

When the computer starts up, before running my program, the memory display shows the module area has 47K free, and largest block 27K. This seems a bit low.

That is normal. The module area is typically only as big as it needs to be, and will grow if necessary. There is an upper limit, but I’ve forgotten what it is.

My guess is that there’s a memory leak somewhere. Check the “System memory allocation” section of the Tasks window when your program has started up, and again after it has been running for a while.

My guess is that there’s a memory leak somewhere. Check the “System memory allocation” section of the Tasks window when your program has started up, and again after it has been running for a while.

Here’s what the memory display looks like after a restart and before running Templogger.
http://www.adamshome.org.uk/RiscOS/memerror/

After ten minutes running, the only change seems to be an increase in the size of the module area. What could cause that? And why is it doing it now, when it wasn’t doing it a week ago, when I haven’t changed anything in between?

Does the module area possibly have a 28MB limit? It’s starting at around 13MB.

Does the module area possibly have a 28MB limit?

Applications are limited to 28MB if you’re running Aemulor. The RMA is normally limited to 256MB.
In your screenshot, it is 13¼MB.

Can you do a screenshot when it fails so we can see where the memory is getting allocated.

when I haven’t changed anything in between?

Absolutely nothing? No OS or firmware update, no software update, no tweaking settings?

After ten minutes running, the only change seems to be an increase in the size of the module area. What could cause that?

Assuming that nothing you are doing would cause additional modules to be loaded, I can think of two reasons for the RMA to get larger:

1. Prior to the introduction of Dynamic Areas in RISC OS 3.5, programs would routinely use the RMA as additional workspace (claiming space with OS_Module 6 and releasing it with OS_Module 7). If a program failed to release space it had claimed, the RMA would continue to grow.
2. Modules themselves could of course be legitimately requesting additional workspace.

And why is it doing it now, when it wasn’t doing it a week ago, when I haven’t changed anything in between?

It needn’t have been a change to the program or the OS. For example, the file(s) you are working with could have been getting steadily larger and may now have exceeded some limit.

Can you do a screenshot when it fails so we can see where the memory is getting allocated.

Once it fails, nothing works. Anything that would open a menu for example fails with something like “insufficient memory”.

It needn’t have been a change to the program or the OS. For example, the file(s) you are working with could have been getting steadily larger and may now have exceeded some limit.

The program adds to a log file every 10 minutes, creating the file if it doesn’t already exist. It also does a Settype on the file after closing it each time. After the last failure and restart, the logfile was around 150MB in size. I’ve since deleted it. The SD card has approx 1.4GB of free space.

If deleting that file hasn’t changed things, then I’d expect it to have failed by tomorrow morning. I now have a Reporter window open on screen, so I’m hoping there might be something in that. The tasks window is also on screen. I will be restricted to what is on screen at the time as nothing I do works at that point.

I should probably have said, that when this has occurred, I come back to the computer, and the program window is no longer there. There is no error display – nothing to indicate the problem except that the program has gone.

As you are running Reporter, the *ReportHeap command will give you statistics of the RMA usage, eg
Heap RMA=&02100000 Max=15360K Size=3852K Free=49920 Largest=13404 Used=3803K (1159) Freed=49728 (27) Unused=192
The numbers in brackets are the blocks in that category.
There is also a block list option, but that is rather verbose for the RMA!
See Help for details.

Once it fails, nothing works.

Leave the memory allocation window open.

When it fails, press F12 then enter *Screensave $.Dammit! and an appropriately named sprite ought to be created.
Of course, this might fail too, but only one way to find out… ;)

It’s starting at around 13MB

I was mildly shocked to see my ARMX6 had an RMA of 2.7MB after booting and setting up DDE for use.

If it were 13MB I’d be calling for the nurse!

Just checked mine. Booted, loaded the DDE, Zap, new stack, and all the usual rubbish, plus NetSurf, and my BBS server, and a program that reads the current weather every five minutes.

The RMA is 5856K.
I have 27½MB of Dynamic Areas (MBufMan 2900K; my server’s IP database 3929K, NetSurf 13120K; obsdfs 1592K, and other stuff like DADebug, disc maps, WebJames cache, and the sprite pool).

RISC OS 5.29 (15-Jul-21; oh, how I wish it would use a full month name and four digit year).

System uptime is 3 days, 0 hours, 53 minutes, and 49 seconds (as I write this).

I find the rapidly growing RMA of the OP to be… concerning.
Did somebody port the Extend virus to be 32 bit?!

Of course, this might fail too

<drops a load of source into Zap>

Hmm… F12 is caught by Switcher that does a Wimp_StartTask “ShellCLI”.

There’s a lot of faffing with handlers, and allocating new application memory.

So far nothing obviously touches the RMA, but something like OS_ReadLine or OS_CLI could bearing in mind there’s all sorts of things like messing with the VDU drivers, redirections, GSTrans, and so on going on in the background.

Oh, no… It looks like ScreenSave creates a temporary sprite header in VDU workspace, but it also needs to allocate some memory in the RMA large enough to handle a scanline’s worth of pixel data.

Well, it might work, but it equally might blow up.

I’d say, try it, see what happens.

I find the rapidly growing RMA of the OP to be… concerning.

It’s not growing now. The first few minutes of running Templogger it jumped to 13616K, and it’s still there a couple of hours later.

The program doesn’t make any RMA allocations – the only connection is Socketwatch.

Reportheap gives Heap RMA=&20000000 Max=256M Size=13616K Free=91K Largest=28588 Used=13524K (1562) Freed=65120 (117) Unused=28592

I’d say, try it, see what happens.

If it fails again, I will.

I’d say, try it, see what happens.

Perhaps take a photo of the screen first, so that you at least have something.

It sounds like Templogger is doing something that’s leaking RMA space, probably a temp RMA allocation that isn’t being freed.

It sounds like Templogger is doing something that’s leaking RMA space, probably a temp RMA allocation that isn’t being freed.

Templogger is written entirely in BASIC. It makes no use of RMA (except that it uses the Socketwatch module, which in turn allocates a small block of RMA for its own use).

It’s now been running for over 24 hours and in that time the module area size has not changed.

The only thing that I am aware of changing between the regular failures and now, is that I deleted the log file it was creating (and several old copies), forcing it to create a new one. AS I recall the log file at that point was about 135MB in size. After the deletes the free space on the SD card is around 1.4GB.

I can’t be absolutely sure that the SD card had not run out of free space, but I can’t see how that could have caused such a drastic cessation of activity from the OS.

There have been comments that the initial size of the module area is unusually large. I cannot account for that. I’ve checked immediately after a cold start and it is already large then, before I’ve started any user applications.

I had a look through the verbose listing of the area produced by Reporter. I was hoping to see a pattern, but the only thing that seemed at all repetitive was a series of “32 bytes allocated” followed by “64 bytes deallocated”. That should decrease the usage, not increase it?

No indication of WHAT was doing that.

There have been comments that the initial size of the module area is unusually large.

Can you drop here the results of the following two commands:

*Modules
*Status

This should show what is being loaded into the RMA, and what your system configuration is (just in case it’s simply a weird configuration).

I am away from home & RISC OS at the moment, but a few comments…

• A large initial RMA may be explained if you have set Reporter to have a very large text area size, as that is in RMA.
• In !Reporter.Examples.Basic the HeapCheck program will run *ReportHeap at intervals, which may be of use.
• What version of SocketWatch are you using? It should be v0.07, from https://www.aconet.org/tools. I have a feeling that under some error conditions previous versions could leak RMA, but only small amounts (though I cannot remember the frequency!)
• If the 32 bytes allocated & 64 bytes deallocated (freed?) were in lots of successive RMA blocks, then perhaps something is claiming lots of 96 bytes then freeing 64 of them?

The 32/64 byte blocks will most likely be the Wimp, as I noted a few years back the Wimp is a major contributor to RMA fragmentation and should probably be using its own private heap for temporary allocations.

I have a feeling that under some error conditions previous versions could leak RMA, but only small amounts (though I cannot remember the frequency!)

16K blocks. In any version before 0.05. Claimed, never used, never released. I can’t remember the frequency either.

the Wimp is a major contributor to RMA fragmentation

A side effect of the legacy, for back in the day it was just easier to grab a bit of the RMA if one wanted “managed” (as in, an existing heap structure) memory that was certain to not be paged out.

What made sense in Arthur/RISC OS 2 doesn’t make so much sense these days. Lucky as machines got faster, memory got larger, which basically papered over the issues.

I’m aware of the horrible because I rummaged around in the Wimp to answer questions like “where are window definitions actually put?”.

But… Menus generated on the fly. Mode blocks for changing mode. Icon blocks. Pixtrans/colour tables. Template loading… Pretty much any time the Wimp needs some workspace, it reaches into the RMA.

What version of SocketWatch are you using?

In fact in this case it turns out I’m not using it. Many of my current programs do, but not this one.
When I do, it’s 0.07

if you have set Reporter to have a very large text area size

It’s set to 10MB – that is the answer then.

Can you drop here the results of the following two commands:

**modules
No. Position Workspace Name
  1 FC0217AC 00000000  UtilityModule
  2 FC047184 20000014  PCI
  3 FC04920C 200001F4  FileSwitch
  4 FC056080 200016B4  ResourceFS
  5 FC056D80 200016F4  TerritoryManager
  6 FC0592C4 00000000  Messages
  7 FC14C71C 200017F4  MessageTrans
  8 FC14DB0C 20003634  UK
  9 FC174DC0 00000000  SharedCLibrary
 10 FC1DAD50 20003ED4  BufferManager
 11 FC1F30C8 20003EF4  DeviceFS
 12 FC1F7CF0 20004034  RTSupport
 13 FC1FB0C0 200069D4  USBDriver
 14 FC207720 2000B794  DWCDriver
 15 FC2886E4 20017894  InternationalKeyboard
 16 FC14F7C4 2001E1F4  WindowManager
 17 FC1700E4 20BC1634  TaskManager
 18 FC174158 00000000  Desktop
 19 FC1A9B78 00000000  BASIC
 20 FC1BAF8C 00000000  BASIC64
 21 FC1CA568 00000000  BASICVFP
 22 FC1DA658 2001BB34  BlendTable
 23 FC1DBFB8 20048EF4  ColourTrans
 24 FC1E0E40 2001B834  Debugger
 25 FC1F55D4 2001A574  BCMSupport
 26 FC1F7278 2001A294  Portable
 27 FC225670 20023874  VCHIQ
 28 FC22CACC 20019894  BCMSound
 29 FC22D458 20044D74  ScreenModes
 30 FC234998 20018054  BCMVideo
 31 FC238078 20BC1174  DisplayManager
 32 FC23A204 2004A554  DMAManager
 33 FC23D1C4 20048434  DragASprite
 34 FC23E980 00000000  DragAnObject
 35 FC23EEAC 2004AC14  Draw
 36 FC2421E4 20BA7834  FileCore%RAM
    FC2421E4 200A5CB4  FileCore%SDFS
    FC2421E4 20061394  FileCore%SCSI
    FC2421E4 00000000  FileCore%Base
 37 FC25628C 20BE5014  Filer
 38 FC25F4B4 2004ADB4  FilerSWIs
 39 FC25F7B0 2004AEB4  FSLock
 40 FC260904 2004B214  FontManager
 41 FC271890 2004C0F4  FPEmulator
 42 FC277E68 2004C254  VFPSupport
 43 FC27FDB4 2004C414  Free
 44 FC2815A8 2004CD14  Hourglass
 45 FC282004 2004CE14  IIC
 46 FC28240C 2004CE34  International
 47 FC29B6A0 2004CE54  InverseTable
 48 FC2A22F0 00000000  NetFiler
 49 FC2A6654 2004D274  NetStatus
 50 FC2A69B0 00000000  Obey
 51 FC2A7360 2004D294  Pinboard
 52 FC2AD114 2004DF74  PipeFS
 53 FC2AE4B4 20BE8894  RAMFSFiler
 54 FC2AF38C 20BE8194  ResourceFiler
 55 FC2AFB58 00000000  ROMFonts
 56 FC304EE8 20048A14  ScreenBlanker
 57 FC305830 2004DFD4  ScrSaver
 58 FC306114 201BC894  Serial%1
    FC306114 00000000  Serial%Base
 59 FC307C9C 20048794  SerialDeviceSupport
 60 FC308374 00000000  ShellCLI
 61 FC3089E4 2004F294  SoundDMA
 62 FC30AD54 2004F4B4  SoundControl
 63 FC30C444 200508F4  SoundChannels
 64 FC30DCB8 20052AB4  SoundScheduler
 65 FC30E6DC 20054AD4  SpriteExtend
 66 FC333298 00000000  SpriteUtils
 67 FC333888 20057C74  Squash
 68 FC3354E8 20058DB4  BootFX
 69 FC337F64 00000000  SuperSample
 70 FC338888 20057A74  SystemDevices
 71 FC339908 2005A634  TaskWindow
 72 FC33BF74 00000000  WindowUtils
 73 FC33BFDC 2005A674  FilterManager
 74 FC33D378 2005A714  WaveSynth
 75 FC33DEFC 2005AEB4  StringLib
 76 FC33EAEC 2005B7F4  Percussion
 77 FC33F7F0 2005C254  SharedSound
 78 FC3411B8 00000000  Filer_Action
 79 FC348464 2005D474  DOSFS
 80 FC3540EC 2005E7F4  SCSIDriver
 81 FC357794 2005FE14  SCSISoftUSB
 82 FC35B14C 200610D4  SCSIFS
 83 FC35C958 20BE92F4  SCSIFiler
 84 FC3610D0 200A2894  SDIODriver
 85 FC36AE20 200A4314  SDFS
 86 FC36F228 20BEA414  SDFSFiler
 87 FC373478 20154934  SDCMOS
 88 FC3737B8 200E73D4  ColourPicker
 89 FC381648 200ED274  DrawFile
 90 FC3871E4 200EEE74  BootCommands
 91 FC389904 200F0674  WindowScroll
 92 FC38B914 200F1974  MbufManager
 93 FC38E020 2013AB14  Internet
 94 FC3AEDD8 2013EC54  Resolver
 95 FC3B99FC 00000000  BootNet
 96 FC3CDC54 20144414  MimeMap
 97 FC3CEFD8 201456D4  LanManFS
 98 FC3EAFF0 20150FD4  EtherUSB
 99 FC3F71CC 20152DB4  DHCP
100 FC3FBE94 00000000  !Edit
101 FC3FEF68 00000000  !Draw
102 FC42CCEC 00000000  !Paint
103 FC44CD34 00000000  !Alarm
104 FC45A13C 00000000  !Chars
105 FC45DE40 00000000  !Help
106 FC4606F8 201559F4  Toolbox
107 FC465244 20157194  Window
108 FC473468 20158CF4  ToolAction
109 FC474F9C 20159F54  Menu
110 FC478FC8 2015B474  Iconbar
111 FC47B904 2015C974  ColourDbox
112 FC47E720 2015DD94  ColourMenu
113 FC4813A4 2015F414  DCS
114 FC4836A8 20160814  FileInfo
115 FC48617C 20161D14  FontDbox
116 FC489EA4 20163354  FontMenu
117 FC48C730 20164834  PrintDbox
118 FC4903DC 20165D54  ProgInfo
119 FC493494 20167274  SaveAs
120 FC496D74 201688D4  Scale
121 FC499308 20169C74  TextGadgets
122 FC4A37C8 2016BA54  CDFSDriver
123 FC4A4CB4 2016C694  CDFSSoftSCSI
124 FC4A71F0 2016F914  CDFS
125 FC4AB45C 00000000  CDFSFiler
126 FC4AE0C0 00000101  UnSqueezeAIF
127 FC4AE3D8 201B6754  GPIO
128 20D2E714 201DE6D4  Reporter
129 FC255788 20BA55D4  RamFS
130 20BA35D4 20BA3594  lprDeviceDriver
131 FC3B9E24 20BB9454  Freeway
132 FC3BDE64 20BBA7B4  ShareFS
133 20BCA2B4 20BC2CB4  Fat32fs
134 20BF2D14 20BEF814  StrongTask
135 20C1B714 20BDDBF4  DitherExtend
136 20C22B34 20C44294  ArtworksRenderer
137 20C4FDB4 20BDD9F4  GSpriteExtend
138 20C571F4 20C61014  GDraw
139 20CA1294 20BDCB54  SpecialFX
140 20CA6E94 20BDFB14  NetTime
141 20CABEB4 20CA5134  PDriverPS3
142 20CC74D4 20BDBDB4  PDriver
143 20CCA274 20CC8DF4  RemotePrinterSupport
144 20CD5DF4 20CD43D4  PDriverPS
145 20CDE9B4 20CD30F4  MakePSFont
146 20BF2194 20BF1074  Dialogue
147 20C179F4 20BF2594  BasicRunner
148 20CD0E94 20C17574  KeyExtend
149 20CEEE34 20CEDB34  ZLib
150 20D00614 20D1B3B4  vncserver
**status
Configuration status:

Baud       4
Boot
Cache      On
No Caps
Num
Data       4
Delay      32
DumpFormat 4
FontSize   256K
Ignore     10
Language   11
Mode       Auto
MonitorType EDID
MouseStep  2
MouseType  7
Print      1
PrinterBufferSize 1K
Quiet
RamFSSize  0K
Repeat     8
RMASize    256K
ScreenSize 160K
Scroll
SpriteSize 0K
Sync       0
SystemSize 32K
TV         0,1
WimpMode   Auto
FileSystem SDFS
Truncate   On
Territory  1
AutoDST
TimeZone   +0:0
WimpFlags  111
WimpFont   8
WimpDragDelay  5 * 1/10 second
WimpDragMove  32 OS Units
WimpDoubleClickDelay  10 * 1/10 second
WimpDoubleClickMove  32 OS Units
WimpAutoMenuDelay  10 * 1/10 second
WimpMenuDragDelay  10 * 1/10 second
WimpIconBarSpeed  200 OS Units / second
WimpIconBarAcceleration  100 OS Units / second²
WimpSpritePrecedence  RAM
WimpButtonType  Click
WimpIconiseButton  On
WimpAutoFrontIconBar  On
WimpAutoFrontDelay  5 * 1/10 second
WimpAutoScrollDelay  5 * 1/10 second
WimpClickSubmenu  Off
FontMax1   16 points
FontMax2   36 points
FontMax3   36 points
FontMax4   16 points
FontMax5   0 points
FontMax    4096k
Country    Default
SoundSystem  16bit Oversampled
SoundDefault 1 7 1
SCSIFSDirCache 255K
SCSIFSDrive 0
SDFSdrive  0
BootNet    Off
FS           (unset)
LMTransport  IP
LMNameServer (unset)
CDROMBuffers 256K
CDROMDrives 0
FreewayAutoAddress Off

Use *Configure to set the options.
*