[sjkrox]

[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).

robert_kennedy2 wrote:
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[0]: (default pager): [KERNEL]: no space in available
paging segments
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
<...ad nauseam...>
Dec 18 12:31:48 halo crashdump[3889]: 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.
---

Additional info:

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.

[gbhardy]

I've a similiar problem and investigated a little bit about the virtual memory consumtion of Toast 7.1.2

I try to create a disk image from three EyTV movies (6.8 GB total size) as DVD with media type DVD-DL.
They were recorded with "High" Quality (DVD 90min) from the S-Video-Input.
Creating the disk image is to avoid DL-Toasters, because while burning directly as exactly the same effect.

Now the description:
After finishing the multiplexing task, Toast starts to write the image. But half the way it stops and clicking somewhere will crash Toast.

The console shows a lot of:

Toast Titanium(1129,0x212f400) malloc: *** vm_allocate(size=8421376) failed (error code=3)
Toast Titanium(1129,0x212f400) malloc: *** error: can't allocate region
Toast Titanium(1129,0x212f400) malloc: *** set a breakpoint in szone_error to debug

before the crash.

At this point (or shortly before ;-)) Toast has used 2GB of virtual memory.

If I remember right, there is a limitation of the maxium of memory an application is allowed to allocate.

Maybe this will help to solve the problem.

BTW: My configuration
MacMini 1,66 Intel Core Duo
1GB RAM
Mac OS X 10.4.8
30 GB free on harddisk
EyTV 2.3.3
Toast 7.1.2

hardy

This post has been edited by gbhardy: 07 January 2007 - 09:05 AM

[sjkrox]

Wow, I can barely believe anyone would still respond about this problem. Thank you!

Both Toast 7.1.2 and Popcorn 2.0.1 can definitely consume excessive amounts of virtual memory under different circumstances, not necessary related to EyeTV recordings. I'm not doing anything fancy and my systems are cleanly configured so it's a mystery why no one else is reporting this.

Regrettably, until Roxio/Sonic shows some sign of interest it just seems a waste of time providing more specific details of the symptoms.

[Greg Meach]

Hmmm I am a heavy user of both Toast 7.1.2 and EyeTV 2.3.x (always kept patched) and I've never run into the problems described here. My main computer is my office Mini w/C2D 1.83 and 2.0GB and more than 50GB free space on multiple drives. I too write disc images before I burn my DVD's. Sorry... I'm of no help and I'm betting since Roxio just announced Toast 8.0 you're out of luck.

The only difference I can comment on is I usually work exclusively on external drives, if that matters.

:-(
Sorry

[sjkrox]

Thanks for the feedback, Greg. Even with gbhardy's information I still don't see any pattern to this. I'd really like some feedback from Roxio and/or Elgato because they obviously have more experience and resources than I do. I'll certainly provide whatever I can (e.g. specific content) that might help isolate this long-nagging problem. I've ordered a Toast 8 upgrade and will known soon enough if that makes any difference.

[freshburn]

The OS handles most of this.

[sjkrox]

freshburn, on Jan 15 2007, 02:38 PM, said:

The OS handles most of this.

Can you elaborate a bit? Then maybe it's the "non-most" part that's troublesome? I don't experience this overt memory consumption issue with any other video-intensive applications I'm using on either system (2GB iMac G5, 1.5GB eMac). It might be more tolerable if dynamic_pager removed extra swapfiles it creates while Toast (or Popcorn) are chugging away, but they want to stick around until a logout or reboot. An unreasonable amount of vigilant and restrictive system usage is necessary when Toast or Popcorn are being used. It's essentially forced me to dedicate blocks of time to "standalone" Toast/Popcorn sessions, which is unacceptable given how long some of the processes take.

I've been a Roxio customer since not long after buying my first Mac in 2001. This is the first time I'm asking for more help to resolve the only significant problem I've had during that time. I'm offering as much of my own time and effort that it'll take to find a satisfactory solution, which may eventually just be better understanding why this can't/won't be fixed. If this weren't important to me or I'd discovered an adequate workaround I certainly wouldn't be bringing it up again over a year since originally reporting it. And I'm not the kind of person who wants help or asks for it unless/until I really need it; I'm usually the computer geek resolving other people's problems.

[gbhardy]

After updating to toast 8 and today to 8.0.1 and MacOSX 10.4.9 there's still no progress to solve this problem.

If someone from roxio needs data to reproduce the problem I'll send a data DVD with the files where's the crash occures.

This software is still unusable for my general purposes for which I use my Mac.

Hardy

[sjkrox]

I don't get crashes (sorry to hear that you do) but Toast (8.0.1) still doesn't throttle its memory usage and the OS never releases the virtual memory swap space long after Toast has quit. Safari, on the other hand, can suck a lot of memory but quitting it will show an immediate reduction in swap space.

[gbhardy]

I'll file a detailed bug report at roxio after this weekend about my issue. Maybe there's some response.
I'll refer the bug report to version 8.0.1 of toast.
So, further discussion from my side will be done in the toast 8 forum subtree.

hardy

[Paul Hagstrom]

See also Toast 8.0.3 in 10.5.1 leaking memory when multiplexing? for a similar-sounding report.