Pi - possible memory leak relating to module data

Title is a very tentative guess so don’t take it too seriously.

Symptom:
After running my Pi system for a while, I start to see memory access errors when loading and using a module. In particular and almost certainly just because it is the one I’ve been testing with, TimerMod by druck. Since this is in use by many apps and I used to for years on an Iyonix I really doubt there is a bug in the module itself!

Some details:
The error always claims (according to `Where`) to be at &714 in the module, a region where it seems a few bytes are being moved around. The code in the area is
MOV r1, #&03200000
STRB r0, [r1, #76]
LDRB r0, [r1, #64]
LDRB r1, [r1, #68]

The error arises both when my app calls SWI Timer_Start, and when using druck’s TimeX obey file, which of course calls the Timer_start swi as it runs.
At least once I’ve also had a bunch of errors in other modules after the first TimerMod related crash, that lead to the entire Filer/wimp crashing, though oddly enough my app was left running and seemed perfectly happy.
I’m fairly sure that on one occasion I was able to rmkill a couple of models, rmtidy, reload TimerMod and have it work, but I certainly won’t swear to that. Similarly I’m fairly sure it has occurred when trying to load and test the HALTimer module.
It’s possible that there is a correlation with having run NetSurf but again I couldn’t swear to it, at least not yet.

Suggestions for further testing to narrow this down would be welcome, as of course, would be solutions.

Anecdata referring to latest state – I’ve had my Pi running for several days now, using !svn and the Estimable Miss Bazley’s !SideDiff and !stronged and the DDE without any issues. What I haven’t run is NetSurf. Now, without any sort of debugger hooked up or some other suitable tools, I can’t make any strong statement but it does increase my suspicion a tad. Perhaps I’ll have the boys bring’im in for a little talk with Dinsdale. For Dinsdale is fair. Brutal, but fair.

Judging by that bit of assembler you’ve posted, TimerMod isn’t 32bit compatible – it’s trying to access the IOMD timer registers. I can only assume you’ve got Aemulor running on your Iyonix, otherwise I would have expected you to see issues there as well.

Are you sure you’re using the latest version of TimerMod from here? It claims to be 32bit compatible, but I haven’t tested it myself to make sure it behaves itself properly on non-Iyonix machines.

Intersting thought Jeffrey but it is definitely the latest posted version
`*help timer mod
Module is: Timer Module 4.12 (04 Feb 2003) [32bit]`
And I’ve just checked to make sure I’m not fooling myself with a hidden away older version anywhere, because I’ve screwed up like that before now…

I must say I was a touch puzzled by the fixed address in the code but it’s been a few years since I had a RiscPC or even an Iyonix so I concluded Druck Knows What He Is Doing. Fairly often a good rule, I find. Best guess – code to handle being on an older system or under Aemulor? Then the question becomes why is it triggered on a Pi and could that cause problems anywhere else?

I did have another very serious crash last night, this time triggering that old fun friend the ‘no stack for trap handler’ error. The address initially shown for the first error was in the range of the module area but I didn’t get a chance to check it before things went very bad. I guess the good news is there was no use of netsurf and so it should be absolved of all blame, released from custody and sent on its way.

If this is a bug for TimerMod under Pi it might be an issue for a number of other applications that make use of it, assuming anyone is using them. Is druck still around hereabouts?

I must say I was a touch puzzled by the fixed address in the code but it’s been a few years since I had a RiscPC or even an Iyonix so I concluded Druck Knows What He Is Doing.

The module is designed to work on both RiscPC and Iyonix. So it looks like it’s either failing to identify the RPi as a RO 5 machine, or it’s getting caught out by changes to the HAL.

Druck is still around so he may be able to fix it.