Runaway RAM Usage leading to Kernel Panic using FilmConvert Plugin (updated x3)

Question

Hello, filed a bug report on this but cuious if anyone sees it.
Late 2012 27 iMac, top line i7 with 680MX, 32 GB RAM.
Promise R6 TB RAID.
Trying to render out a 15 min edit from Premiere that has each clip with 3 filters on it - MB Looks, MB Colorista, Filmconvert.
Since 7.01, every time I render previews or encode out, RAM use skyrockets way past the 25GB I allocated. I get up to a 50GB swap file in fact before the computer just craps out and I can't finish my render. (Nothing past 15 min anyway, I can do under that length ok.) As of this moment PPro Headless in Activity Monior has allocated 40GB and climbing....
Any ideas?  Kind of a major issue. Does not happen on CS6 with same filters and similar project.
PS - The same issue is happening with the same project on my Macbook Pro 15" retina with 16GB of RAM. It's creating a huge swap file. On the iMac with Fusion drive I can't complete the render at all due to the system SSD filling up on the Fusion drive. It eventually crashes and reboots. I can complete the render on the laptop, but it ends up with a 50+ GB swap file.
UPDATE 1:
I had my suspicions a Plugin I am using, the excellent (but now unusable for over 10 min projects) plugin "FilmConvert" was causing the issue on all my Macs.
To prove it's the plugin, I removed duplicated my main 15 min sequence, removed the FilmConvert plugin from all clips while keeping the two Magic Bullet effects on. So, all filters (MB Looks, MB Colorista II) BUT filmConvert.
Result?
RAM usage stays where it should be (at the limit set in Premiere Pro CC) and there is zero swap file usage. Same project, same filters, same everything except FilmConvert was removed on this duplicate timeline.
As it stands, the plugin is unusable for longer projects.  I'm still curious if anyone else has seen this, or if Adobe has any input.
UPDATE 2: I developed a workaround workflow and the vendor wrote back and thinks it's a bug in PPro CC, but will try to see if they can't code around it:
"We have had one other very recent report of this type of behaviour, but when rendering through the CC version
of Adobe Media Encoder or Premiere (but not After Effects). I believe the issue is with Media Encoder / Premiere,
although it's probably preventable within our plugin. The problem I believe is that Premiere and Media Encoder
create many instances of the plugin during a  render, one instance per frame, and it seems in CC those instances
do not get cleaned up until after the render finishes.
As each plugin instance is expecting to be called many times, to render multiple frames, it keeps a certain amount
of memory allocated, in order to gain a speed advantage."
I am using the render previews workflow to deal with it for now. I set my sequence to my master codec (in this case ProRes 422 HQ, with maximum quality checked). Then I preview chunks of the timeline setting in/out, render. Then I quit the program, which frees up the RAM and the need for the swap file, which starts reducing itself. Then I run PPro again, and preview another chunk, and repeat the process until done.
To export final piece, I just export using previews matching the sequence (which is ProRes 422 HQ) and it is a straight copy at that point and quick. This is a useful workflow if you are making tons of minor edits for a client anyway, as it vastly speeds up re-renders of the final file.  No loss in quality as the previews are the same as my final encode would be anyway.
Still, it would be nice if Adobe/FilmConvert or both could fix this bug so I can just queue up a whole sequence and walk away without chunking it up if I need to.
Update 3: If only Adobe could move so fast. Rubber Monkey sent me a new version to test today, and it fixed the problem. Amazing customer service!! It has not been released yet but I suspect it will be at some point. Case closed.

Answer 1

Glad I'm not the only one. My temporary solution was to download the kernel and wl package from December 2012 found http://repo-ck.com/PKG_source/ and then mkpkg and install it. It'll work as an alternative for now, without messing up the primary kernel setup.