I don't have anything but anecdotal evidence for this. I've seen similar issues with Object items for recordsets for larger datasets, but considering the only thing you can do with it is loop it after the fact (other than via .NET) I don't normally hit more than 100 items in my recordsets. I have however seen similar issues for the record count. Width doesn't seem to matter as much, if at all. It's inconsistent however. I've done other tests where I simply created a script source and dumped 5000 ints into the stream to a recordset object directly with no issue.

You might be better off dumping this to a .raw file, but what's the end goal with the recordset data? I don't have a reason it's occurring but I might know of a few workarounds if I know where it's heading.

The fact that the exact same package works with less inputs blows out most of my usual troubleshooting.

GSquared above is absolutely correct, however, SSIS simply uses local windows memory for whatever it needs and will grow to whatever it wants. It ignores SQL Server's cache completely (which means SSIS might be starved if you've got it on the same system as a server leaving only 2 gigs for the OS left, but that's a different problem). The object itself doesn't have any restrictions afaik, unless these rows are rediculously huge (4 gigs huge) and you're in 32 bit mode.

Here's the final curiousity though... Yellow/White/Whatnot occurs during processing. Anything white hasn't even begun to fire yet, but the multicast should already be sending data to it (at least the first row).

What is listed in Execution Results for that task after you've stopped the process? Is it still validating? Does it Prepare for Execute?... you get the drift. Once execute fires it should turn yellow in the interface, but that can get grouchy as we all know.