[Bf-committers] WIndows Nvidia/ATI coders!

[bf-committers@blender.org]

Hello,

I don't know if I found the bug Ton referred to, but I found something weird on 
my win2k machine running a debug tuhopuu2 from visual c++ 6. With a very big 
test scene consisting of 1201 UVSpheres (2064744 Vertices, 2128896 Faces), a 
render eventually crashes every time. Others may be able to reproduce this on 
other platforms by making such a huge scene (SHIFTKEY+D) of the same object, so 
that the internal Blender limits are reached. My objects were UVSpheres, so 
maybe that had something to do with it.

Here is an overview of the functions on the stack trace:
void oldRenderLoop(void)
prepareScene()
RE_local_get_renderdata(void)
RE_rotateBlenderScene(void)
init_render_mesh(ob)

I tracked the crash for my scene to init_render_mesh(), line 1648 of 
convertBlenderScene.c, where an attempt is made to access a bad "vlak" returned 
from RE_findOrAddVlak(). This fails on the second line:

vlr= RE_findOrAddVlak(R.totvlak++);
vlr->v1= RE_findOrAddVert(vertofs+mface->v1);

This seems to be a "one-off" error where the RE_Render->blovl vlak array is 
accessed one element past the end of the memory allocated it. This happens when 
R.totvlak == MAXVLAK, and therefore blovl[MAXVLAK] is one too many. Here is 
where this is SUPPOSED to be avoided in RE_findOrAddvlak() at line 123 of 
renderdatabase.c:

if(nr<0 || nr>MAXVLAK ) {
	printf("error in findOrAddVlak: %d\n",nr);
	return R.blovl[0];
}

If this is executed, rather than getting the vlak from blovl[nr>>8], it returns 
the first one and prints out a message. So, how about changing the first line 
to??:

if(nr<0 || nr>=MAXVLAK ) {

Well, you get a bunch of print statements of an error. THEN, since that call to 
RE_findOrAddvlak increments R.totvlak, this stuff at line 265 of renderHelp.c 
fails:

for(a1=0; a1<R.totvlak; a1++) {
	if((a1 & 255)==0) vlr= R.blovl[a1>>8];
	else vlr++;

So it seems that totvlak should max out at the MAXVLAK? I find this increment 
all over the place in convertBlenderScene.c, so maybe this limit is RARELY 
reached??? Adding this line after the findOrAddvlak() call seems to do the 
trick:

if(R.totvlak>MAXVLAK-1) R.totvlak = MAXVLAK-1;

The only problem is that I get a "Memoryblock free: attempt to free illegal 
pointer" message in the console after rendering finishes, which happens here, 
line 283 of mallocn.c:

if (((long) memh) & 0x3) {
	MemorY_ErroR("free","attempt to free illegal pointer");
	return(-1);
}

I can see that it is trying to free the last element of the blovl array, which 
is non-zero, but not valid. Another one-off problem traded for the one I fixed, 
but no crash. Needless to say I know next to nothing about what al this code 
does, I am just looking at it from the perspective of a novice with a stack 
trace ;) BTW, I got the same crash with this scene in Publisher 2.25.

Thanks for any comments,
Tom


Quoting Tomas Golembiovsky <nyoxi@seznam.cz>:

> I made some researches and it probably isn't problem with graphics 
> cards. Can somebody confirm this bug on platforms *other* than Windows?
> 
> Ton Roosendaal wrote:
> 
> > Dudes!
> > 
> > This bug is popping up a while now:
> > 
> > --------------
> > http://projects.blender.org/tracker/ 
> > ?func=detail&atid=125&aid=475&group_id=9
> > 
> > During blender is rendering a image, We press F12
> > button, Then Blender is crashed after rendering is
> > finished.
> > 
> > When crash, dos window displays "GHOST event error -
> > invalid window-win:00F6C30(example)" or
> > sometime "Memoryblock free:attempt to free NULL
> > pointer". It happened when blender is rendering heavy
> > scene(spend much memory).
> > I tested this problem, Blender crashed with access
> > violation.
> > -------------
> > 
> > The 'ghost event error' pops up more often it seems...
> > The person who fixes it gets eternal fame!
> > 
> > -Ton-