After some focused investigation tonight, I've found that this memory leak seems to happen whenever the Project Media tab is frontmost. After adding just a few mixed pieces of media (latest test was just two MJPEG/AVI at about 30-45 sec each, a single PNG still, and about 5 uncompressed WAV files at about 5-8 sec each), the simple act of opening that project and doing nothing else would start eating up my available ram at about 300MB/sec until all 32GB was used.

Switching or alt-tabbing to any other application would temporarily halt the memory leak, but switching back to Sony Vegas would continue it again. Creating a brand new project does not immediately present the leak again, but the used memory is not freed. Only quitting the Sony Vegas app frees the memory.

General instability occurs after a sizeable amount of memory is allocated this way. For example, attempting to render the project often crashes in mid-render (I sent the crash reports), and chances of crash seemed to be related to percentage of total memory allocated, e.g. very high chances when 21/32GB used up by leak.

"I've found that this memory leak seems to happen whenever the Project Media tab is frontmost"..

As a guess, it could be thumbnail generation related. Have you tried changing the project media view mode to either details or list etc? Some mode other than thumbnails. If that stops the memory useage, then it would indicate a problem in this area.

Paul.

Hi stellarfirefly, thanks for reporting your experiences. And thanks for including your basic system specs, although it would be most helpful if you could add and enable them in your forum profile, so that we can check them on future posts. Also, please do include your GPU/graphics card and driver version, as this may be relevant.

Finally, one more question: you mentioned that you're using MJPEG and AVI (as well as some other formats; PNG, WAV...), however both of these have many variants. What are the sources of these clips? The more specific, the better. Thanks again.

Best,
Paddy
SCS

I can think of four things to look at:

1. As Paul suggested, change your project media view to another mode, like details or list. It could be that Vegas is tripping over thumbnail creation.

2. Turn off Auto Preview in the Project Media window.

3. Simplify the problem. Start a new project file and just put one type of media into the project. Repeat the process for each type and see if one of them is the culprit.

4. Lastly, just check your preview RAM settings. This shouldn't be an issue for the Project Media window, but you should still try opening Vegas with the setting down around 512 MB or less, just to eliminate this as a possibility.

Since this doesn't happen to everybody I'm guessing it's specific to the media you're using. Even so, Vegas should be better behaved about it.

Rob

<edit> I just reviewed what you wrote and see that this happens with several types of media. I'd still try to narrow it down in a simple project with one type of media in the project but no tracks in the timeline. Do you have any third party codecs installed?</edit>

Thanks for the quick response! I checked the box to display my system specs, but didn't realize that there was separate page to specify it; I've filled that out now. It didn't have a field for GPU driver version, but I'm using NVidia's 296.10 drivers, latest non-beta as of today.

The guess about thumbnails seems to be spot on. Switching to list or detail view halts the memory allocation, and switching back returns to "eat it all up mode". I can easily recreate the problem with two short MJPEG/AVI clips (41s+19s). One oddity which may be a clue is that both clips are required. Adding either one of them singly does not result in unstopped memory allocation. Adding the second, regardless of which one is second, slowly eats memory (though much more slowly than the original test project, which had 2 more clips, about 5s each).

All clips in this test project were Blender 2.62 animations saved as MJPEG. I saw this behavior with video from another source in the past, but I am still trying to remember exactly which one and recreate it. I'll re-post once I find out.

In case the remaining suggestions may be of use:
1. Detailed above.
2. I've always had auto-preview turned off. The above behavior seems to be with simple attempted thumbnail creation. (!) It may be worth noting that for the clips in question, no proper thumbnail is ever created, not when there is a single clip with no memory leak, and not when there are two clips and memory appears leaking.
3. Detailed above. No single clip seems to be the culprit. In fact, I just recreated the issue with two 250-frame clips
4. Preview RAM has always been set to only 200MB.

Best guess so far is that Blender (and whatever that other app from the past) is creating improperly formatted files, but perhaps at least Vegas can be better about detecting such problem files and not infinitely attempt to thumbnail them. However, the fact that two clips are required to trigger this behavior suggests that perhaps at least part of the issue lies within Vegas itself. In either case, I'm just going to leave that tab in Detail View for now. :)

yup, sounds about right. Some combination of thumbnail generation and codec type is probably not working correctly together.
As a suggestion to help further identify the issue, you may want to download MediaInfo, if you dont have it already its available for free here:
http://mediainfo.sourceforge.net/en/Download

Then drop your MJPEG issue file into it and get a detailed readout of the file type. Thats useful information for the SCS guys. Or, as you said, post a clip and let them do it.

Rather than calling it a memory leak, its more like a process that is not ending. Stuck in a loop allocating memory to produce the thumbnail. Could happen when the end of file data is not being read form the codec. So it never ends! But thats speculation.

Good luck with this, sounds like a bug. Over to SCS!

Paul.

I use GSpot myself, and the report showed nothing at all out of the ordinary so I didn't think to post that info. But just in case it is useful:

Container:
File Length Correct
AVI v1.0, "rec list" style
Video: 13.4 MB (99.89%)
AVI Overhead: 14.6 KB (0.11%)

CODEC: MJPG
Name: Motion JPEG
Status: Codec(s) are Installed

...as an example of one of the 8s clips. The others are all similarly plain.

Each thumbnail takes 4Kb of RAM, unless you are formatting with exFAT, then each thumbnail takes 32Kb. (3GB drives may be formatted using exFAT).

A memory leak occurs when a program or process does not release the memory assigned to it when it closes. (As opposed to programs that remain in memory after they are closed - like MS Office).

How to test for a real memory leak:
1. Check the available RAM (Resmon.exe)
2. Run a program and exit it.
3. The available RAM should be the same as in step 1.

If the available RAM is lower, then run and close the program again. And again. If the available RAM keeps going down then the program or one of hundreds of processes it calls is not properly releasing the RAM it took to run.

Thats not strictly correct Steve, memory leaks can (and mostly do) occur during the execution process. A memory leak is simply a memory resource that has been allocated (in C++, this is done using a 'new' command) and then not released after its use (again c++, this is done with 'delete').
If you allocate a memory block and then dont release it (still during execution) you will then see a memory leak situation.
You will only see the start program / end program memory problem if the memory is allocated at the start of execution and then not released when exiting.
So even though the memory can show the same figure on program exit, you can still have a memory leak while its executing.
It really depends on where its allowcated and then de-allocated and programmers are supposed to know exactly how to do this, even when things go not to plan, like a faulty file or faulty codec, the 'delete' should still be carried out in unknown conditions. Thats good programming.

Paul.

"A memory leak is simply a memory resource that has been allocated (in C++, this is done using a 'new' command) and then not released after its use "

I think that's what I said. I didn't want to get into the programming details, but the result is the same. On your latter example, a run-time leak is rare in the wild because such a leak shows up rather quickly during development.

I definitely remember a similar problem with Vegas and thumbnails. I remember that having either certain effect's or transition's thumbnails displayed caused Vegas to crash. I know that is not very helpful because I cannot remember if it was in Vegas 9 or 10 and cannot remember specifically which thumbnails were being displayed but I do remember when changing the display to text or details only, the crashes stopped happening.

I'll have to see if I can find an old trouble ticket email to refresh my memory, but it's possible that was related to one of the current problems some of us are experiencing. I just never associated it with a memory leak issue, I always thought it had something to do with my video card or driver.

Would it be helpful if we all checked:

1) Memory Leaks

against

2) Thumbnails on/off (detail view off/on)

Would that be useful?

Grazie

Erased double message.

Cyber thanks!

Grazie

@Grazie:

Was that a memory leak... :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

< ")%%%><(

Now, any thoughts on my well meant posting?

G

I forgot what you said.....

Grazie, yes it could be worth us checking this, but it appears this is only happening with the OP's MJPEG files and nothing else. So unless we are using Mjpegs, i doubt we will see anything.

Sorry for my long winded post earlier, all i was really saying was checking for Ram resources after a program start/stop is not nessasserily going to tell us if there was a memory leak. But i got into the nuts and bolts of why.
Memory leaks happen mostly 'during' a programs run time. Preciesly because the software programer didnt do his job right. But in fairness, its a hard job to do - spotting when to close a resource (delete ram allocation) after somthing breaks. Thats the skill of a good programmer.

In this case, the OPs situation doesnt really look like a memory leak at all.
Its a stuck operation, in a loop, allocating memory over and over. And this is backed up by him saying the thumbnails are not displayed fully. Something is crashing internally (not the whole app) making it look like a memory leak. Resources are being gobbled up without even doing anything.

Anyway, like already said, its up to SCS now, they are in control of the source and there is nothing we can actually do about it other than speculate. But at least the OP now has a work around and can hopfully get him going again.

Paul.