Hi everyone and thanks for chipping-in.
A few clarifications, whilst i continue to track down the issue:
a) This is being run on a Min 1.89 QL, no SMSQ/E here. I'm going to try Min 1.98 - just in case...
b) I do not make any (explicit) allocations at all - not even LRESPRs in the app itself. That said, I make much use of a (customised) DIYTK routine to handle screen-area saving (those W_STORE/W_SHOW extensions) which themselves allocate memory. I'll check the logic...
c) I use the DIYTK Timers, but then I also use them in other TURBO'd apps that don't exhibit this behaviour. They are disabled before termination with T_OFF - I'll try placing the T_OFF in the SB wrapper that starts the job itself...
d) I use the TH_LOAD/TH_USE/TH_FREE/TH_REMV routines from the Thing extension - but I've checked I've paired off every TH_USE with a corresponding TH_FREE before TH_REMV.
As for what the app actually does, well it may not shed much light, but it tracks and displays timings of the Scalextric cars passing over sensors on the track - monitored via some free input pins on Hermes. In the process, race timings and individual lap times are recorded between sessions against named 'drivers' (selectable from a list before each race.) The main race timer is displayed using custom 'sprites' like an old-fashion 7-segment-like LED display (actually just partial screen-saves, displayed using a variant of W_SHOW).
To facilitate the reading/writing of the various race-stats and other data (like drivers names), I use the MEM device (again, heavily customised!) mapped over the memory that TH_LOAD allocates when I read the data from storage (SDC). I take care of EOF (so as not to overwrite beyond the end of the allocated area) with a combination of the adjustments to the MEM device code, plus some simple SB.
I also implemented 'marque' text banners that scroll across the screen, alerting the drivers during the race. I remember being quite proud of that routine - a simple state-machine, called periodically to advance each scrolling window, based on individual timers. In fact, as a project (over a couple of years, now I think of it), I was able to stretch my programming skills and the humble QL - all in SuperBasic plus extensions - it was only due to the slow timer-display updates that I then started to compile in Turbo to keep up with the action!
...Well, you did ask, Tobias...
Here are some screen-captures of it running (in 'debug' mode - where it doesn't try to access Hermes) on QPC2 - oh, and it doesn't hang in SMSQ/E, but thats not much of a comparison.