render problems

[jbills]

I am continually getting an error when going to render here. I've got the longest shot I've put through s+r, and that must be causing the problem.

It's a 260 frame shot, 2k cineons. I'm working at 8bit to save space.

I get about 230 frames into the render, and it crashes, giving me a "St9bad_alloc" error box.

I've tried to reproduce, and I can get it to crash consistently but on different frame numbers. Frame 130, 204, etc. I think this might have something to do with my cache and how s+r is pulling in and out frames.

I'm able to continue renders by restarting and setting the work area. Although - for some reason, it's not rendering my last frame (stops at 259)?? :confused:

I've got 4 gb of ram, my sys swap drive is 3 gb. My max ram pref is currently set to 3771 (have been experimenting with that, thinking that might help).

I was also getting this exact same error when tracking the other day.

any ideas?

[jbills]

was able to get that last frame by parking my playback head on the last frame an "rendering current frame."

strange. can't seem to reproduce it consistently, but yeah, had 2 renders end a frame early.

[perryk]

J, I'm really sorry we're all at NAB. We prefer being responsive to problems immediately. This will have to wait until next week, unfortunately.

[jbills]

hey, no problem - just putting some stuff in the queue for afterwards. No worries!

related to this thread - I'm on a dual Xeon box. although I think most of our dept is and no one else is getting this error.

wonder if it might be video card related but I'm not seeing the "disable shaders" box on the linux build.

[jbills]

hmmm... setting the memory limit in prefs to below 2 gb solved the problem.

is s+r multithreaded? seems like it should be 2gb per process, no? So when it comes render time, in theory it should be able to access beyond 2gb if detecting 2 32bit processors, no?

I could very well be smoking crack? But I know our blade renderwall servers have 6gb of ram, so you would think that it could be accessed somehow. Although I think I heard the IT guys mention they were running some 64 bit extensions...

[perryk]

Threads are not different processes. They live in the same address space.