Using a file that I’ve successfully rendered more than a hundred frames from under 2.57rc2, I now get an odd crash rendering from 2.57 release (Win32 version).
I’ve set things up to render 25 frames, but in three tries now, Blender crashes after completing one render. This is the error message:
e74 blender.exe - Application error
The exception Integer division by zero.
(0xc0000094) occurred in the application at location 0x691ce026.
I can’t say for certain since the UI isn’t available after the crash but it happens either in the “Preparing scene data” or the “Raytree building” stage of the render pipeline, not during the render of parts. I switched from the SIMD SBVBVH acceleration structure to “Auto” after the second crash but it still happened.
The machine this happens on is running WinXP Home Media Center SP2, and is rather RAM-starved (968Mb). But the earlier successful renders included 5 particle systems that are not being rendered for this pass, nor am I getting the Blender console error line (usually “malloc yada yada yada”) that usually accompanies a memory-related crash.
On another machine (it has better RAM specs but also runs WinXP), the same file had a few memory-related crashes at first but is now churning out frames just fine, and never popped up a divide-by-zero error. It has never crashed my Win Vista machine (still running 2.57rc2).
Any ideas? Divide-by-zero is pretty unusual. I’m surprised to even see it.
EDIT: Tried the file in 2.57rc ( the latest before the release). Now, despite having less to render (because of the 5 hidden particle systems), it crashes from memory overload (console reports a “Calloc…” type error). Crash occurs during “Raytree building.” But no divide-by-zero. I don’t get it.
Very strange. Is there a way you can make the file generic and submit it as part of a bug report? Or, worst case, post it here so other folks can try to reproduce it?
Because of the 13 particle systems this file uses, it weighs in at over 250 MB, and I’d also have to supply the external cache – 209MB! No chance of putting it up as an attachment, nor with a bug report. Not even sure it would compress enough to put on my cdupload account (max 100Mb file size). And of course it renders fine when reduced to just geometry (about 3.5Mb).
I’m sure the bugbusters would dismiss it as a low-mem or Windows-related problem, given that many of the crashes are due to a lack of RAM resources. I have no big issues with the memory-related crashes (other than I think they could be handled more gracefully by Blender), that’s as much a Windows prob as Blender (though Blender 2.5x does seem to require an extraordinary amount of RAM compared to 2.49b). But the divide-by-zero is a bit disconcerting. If that’s a truly accurate crash error report – it was generated by Windows, which does little to create confidence in its accuracy.
Yeah… the debugging tools on live builds in Windows leave a bit to be desired. Otherwise, I’d suggest you run Blender through gdb and see what the backtrace gives you.
Wish I knew what that means :o without asking. At least I understand “backtrace.”
@ Nico_GA: I’ll give that a shot, since the same machine is throwing up the same Divide-by-Zero message when working on other frames in the file that have absolutely no particles and even less geometry.
EDIT: After running on debug with an open console window, it seems that this file under 2.57release is now using significantly more memory than under 2.57rc2, because it’s a “Calloc returns null:” error, not (as dumb-ass Windoze reports) “Divide-by-zero.” That must be a fall-back description or something. I’d just never encountered it before.
But I’m still puzzled why the same file could be rendered previously with no problems, and now (with fewer memory-chomping bits & pieces in the render pipe) it chokes.
Sorry about that… gdb is a debugging program that ships standard with many Linux distros. This error intrigues me, though. I’m tempted to set up a virtual machine with drastically reduced memory and see if I can’t reproduce your error on different operating systems. Perhaps if I have some free time this weekend…
Here’s another little 2.57 surprise – a couple of very simple materials (standard Shading specs, no textures, no SSS or other bellsy whistles) have somehow been completely broken compared to what they were in 2.56beta, appearing nearly black. I switched versions because 2.56beta was glitching my bump maps, but failed to notice (until I’d rendered a pile of frames :() that these materials had also been affected. Now I have to troubleshoot that issue, and somehow find a way to re-render a couple hundred frames to exactly match those already done the way I want them, in spite of 2.57’s cavalier treatment.
My bad. The objects in question were originally assigned to two layers (one for lighting, one for working on them apart from the other geometry) but somehow that changed to only one – of course, not the one with the Layer-only lights :rolleyes: I don’t recall disabling any layers for these objects but I can’t say for sure I didn’t, even inadvertantly, so I guess I’m due a head-smack.