[This is a re-post of a message from last December on the pre-upgraded forum]
Hi, Rob. I took a short break from a partly frustrating Toast marathon for an infrequent visit here to look for posts related to memory usage (mostly) and happened to find yours (with its clearly descriptive subject).
That's odd, no one else has this problem?
I most definitely have the same problem you described with Toast (7.0.1 on 10.4.3) consuming every bit of my iMac G5's 2GB RAM + VM it can while creating Video-DVD from EyeTV 200 MPEG-2 recordings. And it's generally not well-behaved with memory usage in other scenarios either, which I'll ignore for now to focus on your specific example since it's been crippling my system this weekend. Here's a summary:
Toast has been triggering dynamic_pager to create four or five new swapfiles in /var/vm. Soon after that this message appears in /var/log/system.log:
Dec 18 12:20:49 halo kernel: (default pager): [KERNEL]: no space in available
At that point there's about 8GB available on the startup volume, which I'd expect to be enough space to create another swapfile. Toast still keeps running, but when quit only one swapfile might eventually disappear.
I've been able to avoid that by rebooting the iMac, logging in with Login Items disabled, and keeping system usage minimal except to run Toast (starting by giving it as much RAM/VM as possible). And by restarting Toast between memory-sucking "sessions", e.g. creating a disk image from a set of EyeTV recordings, only one additional swapfile is created. If I don't restart Toast then the swapfile parade will start, and might also generate these console log messages:
Toast Titanium(3417,0xa000ed68) malloc: *** vm_allocate(size=8421376) failed (error code=3)
Toast Titanium(3417,0xa000ed68) malloc: *** error: can't allocate region
Toast Titanium(3417,0xa000ed68) malloc: *** set a breakpoint in szone_error to debug
Dec 18 12:31:48 halo crashdump: Toast Titanium crashed
Which always ends with a crash. I can relaunch Toast and successfully rerun that particular Toast session without rebooting, but the swapfiles will remain.
This sort of misbehavior is consistently reproducible.
One last point to mention (maybe unrelated) is that the iMac froze (full-blow fans, no kernel panic) near the end of the first Toast session on Friday, somewhere near the end of multiplexing and before starting to write a disk image. After doing system integrity rituals I decided to conservatively limit activity mostly to Toast, which is how I discovered what I just wrote about memory usage. First time the system's locked up that way since getting it repaired several months ago and it hasn't happened again since Friday.
That's basically it. I'm somewhat distracted by getting this burning project finished so specific details, like the exact number of swapfiles after the "parade" starts, may not be 100% accurate but that seems irrelevant to the problem.
Hopefully Roxio support folks will notice this followup and give us (and anyone else who's interested) some feedback. It's really bugging me (pun intended) to be using Toast and my iMac this way.
I've only had one iMac freeze-up since then but the problem with excessive virtual memory use and generally poor system performance still occurs when using Toast 7.0.2 on OS X 10.4.5.