[Bf-committers] Blender 2.43 RC1

Giuseppe Ghibò ghibo at mandriva.com
Tue Jan 2 00:31:13 CET 2007

Ton Roosendaal wrote:

> [...]
>> We also could use backup compilers for official builds, like for
>> Linux. Anyone?
>> (Would be nice if someone who already does a lot of informal testing
>> builds joins our team)

Dear Ton, I tried to compiler current 2.43-RC1 (indeed also today CVS
20070101, instead of "20062812 13:54 which was RC1") under Mandriva Linux 2007.0 for
both i586 and native X86_64 platform. Here is a little report about testing

1) I found that recently into source/blender/blenkernel/BKE_plugin_types.h
the size of the 'name' array was increased from 16 to 32. Indeed when it
was 16 I was also getting a buffer overrun, as described here:


and I wrote a patch for 2.42a here:


Indeed apart the increasing of the size of the array from 16 to 32 bytes,
that code from 2.42a to current CVS wasn't changed, so the bug is still there (just shifted).
Would be possible to include this patch:


into current blender CVS, so to perform a more robust
check over that arrays?

2) The blenderplayer binary is built only when both the

	WITH_BF_PLAYER = 'true'

are specified, but if only WITH_BF_PLAYER = 'true' is set (leaving
WITH_BF_GAMEENGINE as default), the build ends in a linkage error of
the kind:

/usr/lib/gcc/x86_64-mandriva-linux-gnu/4.1.1/../../../../lib64/crt1.o: In
function `start': (.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status

Is this normal (i.e. having to set both vars for the purpose)?

3) I see the ChangeLog file in the cvs is currently outdated. Would
be possible to update it? Using the utility 'cvs2cl' inside the
current cvs would just do the trick, providing an uptodate ChangeLog
extracted from cvs.

4) Using a little bit stronger optimization than default one (i.e. the
same optimization under which the 2.42a was working fine), the
resulting binary won't start. The backtrace of the 64bit version is

Thread 1 (Thread 47614455580656 (LWP 30612)):
#0  0x00002b4e18c4afb5 in raise () from /lib64/libc.so.6
#1  0x00002b4e18c4c5b0 in abort () from /lib64/libc.so.6
#2  0x00002b4e18c8130b in __fsetlocking () from /lib64/libc.so.6
#3  0x00002b4e18cfaf8f in __chk_fail () from /lib64/libc.so.6
#4  0x00002b4e18cfa549 in __sprintf_chk () from /lib64/libc.so.6
#5  0x00002b4e18c84b0e in _IO_default_xsputn () from /lib64/libc.so.6
#6  0x00002b4e18c5d701 in vfprintf () from /lib64/libc.so.6
#7  0x00002b4e18cfa5ed in __vsprintf_chk () from /lib64/libc.so.6
#8  0x00002b4e18cfa530 in __sprintf_chk () from /lib64/libc.so.6
#9  0x00000000008e6fd8 in write_file_handle (handle=Variable "handle" is not available.)
    at source/blender/blenloader/intern/writefile.c:1853
#10 0x00000000008e8a76 in BLO_write_file_mem (compare=Variable "compare" is not available.)
    at source/blender/blenloader/intern/writefile.c:1984
#11 0x00000000008b12d6 in BKE_write_undo (name=0x0) at
#12 0x000000000064e3b4 in BIF_read_homefile () at source/blender/src/usiblender.c:518
#13 0x000000000064e597 in BIF_init () at source/blender/src/usiblender.c:860
#14 0x00000000004f11e0 in main (argc=1, argv=0x7fff93f9d088) at source/creator/creator.c:462

I've had not yet the time to debug the code more deeply, but seems this
line 1853:

	sprintf(fg.subvstr, "%4d", BLENDER_SUBVERSION);

in the file source/blender/blenloader/intern/writefile.c triggers a buffer oveflow.
Changing to a more safe:

	snprintf(fg.subvstr, sizeof(fg.subvstr), "%4d", BLENDER_SUBVERSION);

seems fixing it (although apparently the original code sound correct). Compiler used is
gcc 4.1.1.

5) I've noticed that under Matrox G450/G550 card with DRI acceleration
the menus are messed up (overlapped, etc.). This bug was there
since 2.41. Any chances for it?

I've still two points/question/suggestion for the yafray section as well as the current maximum
number of threads, but for this, later.


More information about the Bf-committers mailing list