[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/render/intern/source initrender.c

Ton Roosendaal ton at blender.org
Thu Jan 12 13:21:52 CET 2006


This is the weird thing in the backtrace:

>> #1  0x005edd87 in shadepixel (x=0.0500000007, y=-0.0125000002,  
>> z=2147483647,
>>     facenr=0, mask=255, col=0x22fa50, rco=0x22f9c0) at  
>> rendercore.c:2327

Here everything is fine, it are valid numbers to call the function  
with. Also looks like it is the first pixel being rendered. facenr==0  
means it is the sky.

>> #0  0x005fd632 in RE_findOrAddVlak (nr=8388607) at  
>> renderdatabase.c:317

Now when it enters shadepixel(), the value of "facenr" suddenly becomes  
huge... at that moment the stack is corrupted... but the initialization  
that happens in beginning of shadepixel seems to me extremely harmless.  
The stack at that moment does get a big jump forward, with the  
inclusion of the two structs:

	ShadeResult shr;
	ShadeInput shi;

ShadeInput is about (estimate) 500 bytes large. Well... for a stack  
that should be no problem. Unless theres some setting in the gcc  
compiler present (is that possible) that has limited the stack to some  
minimal value?

A possible test can be to move these 2 structs out of the shadepixel(),  
make it globals for the time being. You cannot do threaded render then,  
but further should work OK.


On 12 Jan, 2006, at 1:38, Joe Eagar wrote:

> Chris Burt wrote:
>> Hey all,
>> Still cannot render with Orange Branch on Cygwin/Windows/GCC.
>> Work by Hos indicates that build started crashing 12/28/05 with  
>> commit by Ton dated: Wed Dec 28 16:42:55 CET 2005
>> This makes things hard to narrow down because it was a monsterous  
>> commit (about 50 files changed/added) and probably has a lot of work  
>> done on the renderer.
>> Not quite sure how to fix this situation. I've included a backtrace:
>> #0  0x005fd632 in RE_findOrAddVlak (nr=8388607) at  
>> renderdatabase.c:317
>> #1  0x005edd87 in shadepixel (x=0.0500000007, y=-0.0125000002,  
>> z=2147483647,
>>     facenr=0, mask=255, col=0x22fa50, rco=0x22f9c0) at  
>> rendercore.c:2327
>> #2  0x005ee9e4 in shadepixel_sky (x=0.0500000007, y=-0.0125000002,
>>     z=2147483647, facenr=0, mask=255, colf=0x22fa50) at  
>> rendercore.c:2603
>> #3  0x005eee6b in do_renderlineDA (poin=0x22fbc0) at rendercore.c:2853
>> #4  0x005efbe7 in zbufshadeDA () at rendercore.c:2995
>> #5  0x005e6fe4 in render () at initrender.c:1069
>> #6  0x005e8002 in RE_initrender (ogl_render_view3d=0x0) at  
>> initrender.c:1434
>> #7  0x00419f0c in do_render (ogl_render_view3d=0x0, anim=0,  
>> force_dispwin=0)
>>     at renderwin.c:1076
>> I hope this helps someone more knowledgeable with the problem. To  
>> everyone else who has worked on this and has a better understanding  
>> of the issue, if you could add the results of your research to this  
>> it would be appreciated. I'd like to be able to go back to using  
>> Orange for real work and this seems to be the only kink.
>> Thanks for your time folks!
>> Regards,
>> --Chris
> The problem is a memory corruption error.  On my build I actually  
> could make a cummy char array (about 5 bytes) that would make it work,  
> which seems to confirm a memory corruption error. Unfortunatley, this  
> isn't a heep error, the internal memory stack (and possibly some of  
> the execution code) of shadepixel itself is getting corrupted.
> And for the life of me I can't figure out what's going on.  Is a  
> function pointer to shadepixel being passed around somewhere?
> joeedh
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
Ton Roosendaal  Blender Foundation ton at blender.org  

More information about the Bf-committers mailing list