# [PC-BSD] Possible regression in 9.0RC3



## sambler (Jan 10, 2012)

I am running FreeBSD amd64 9.0 RC3-p1 (PC-BSD system install with freebsd-update to p1).

Running blender I have found a scenario that fails on FreeBSD 9.0 amd64 that works fine on 8.2 x86.

Running blender through gdb I get -

```
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 80cc07400 (LWP 2421109/blender)]
0x0000000802e1ee6b in std::ostream::_M_insert<double> (this=0x7fffffffc6f0, __v=27) at ostream.tcc:221
221	ostream.tcc: No such file or directory.
	in ostream.tcc
Current language:  auto; currently c++
(gdb) bt
#0  0x0000000802e1ee6b in std::ostream::_M_insert<double> (this=0x7fffffffc6f0, __v=27) at ostream.tcc:221
#1  0x0000000000ce297b in calculateMemreqEstimate ()
#2  0x0000000000d0f6fd in elbeemEstimateMemreq ()
#3  0x0000000000f8e6f5 in RNA_property_string_get ()
#4  0x0000000000f8ee2e in RNA_property_string_get_alloc ()
#5  0x0000000000a3db56 in pyrna_prop_to_py ()
#6  0x0000000000a3de1f in pyrna_struct_getattro ()
#7  0x00000008036a7d9f in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.2mu.so
#8  0x00000008036ae47a in PyEval_EvalCodeEx () from /usr/local/lib/libpython3.2mu.so
#9  0x0000000803644872 in PyClassMethod_New () from /usr/local/lib/libpython3.2mu.so
#10 0x0000000803621e6d in PyObject_Call () from /usr/local/lib/libpython3.2mu.so
#11 0x0000000000a3f56b in bpy_class_call ()
#12 0x000000000101588c in panel_draw ()
#13 0x000000000095d44c in ED_region_panels ()
#14 0x00000000007683a6 in buttons_main_area_draw ()
#15 0x000000000095fa05 in ED_region_do_draw ()
#16 0x000000000074d30c in wm_draw_update ()
#17 0x000000000074bb64 in WM_main ()
#18 0x000000000074a554 in main ()
```

I have tried combinations of gcc/gcc46 -O1 -O2 -O3 (clang fails to build as yet)
I have run official binaries made by blender foundation (2.57/2.58/2.59/2.60) as well as my own svn builds and port build.

For testing - I am simply setting an object to be a fluid domain. In the physics properties add fluid and change the type to domain.


----------



## plamaiziere (Jan 10, 2012)

sambler said:
			
		

> I am running FreeBSD amd64 9.0 RC3-p1 (pcbsd system install with freebsd-update to p1)
> 
> Running blender I have found a scenario that fails on FreeBSD 9.0 amd64 that works fine on 8.2 x86
> 
> ...


----------



## sambler (Jan 11, 2012)

```
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 812c07400 (LWP 103019/blender)]
0x0000000802e27e6b in std::ostream::_M_insert<double> (this=0x7fffffffc7c0, __v=27) at ostream.tcc:221
221	ostream.tcc: No such file or directory.
	in ostream.tcc
Current language:  auto; currently c++
(gdb) disas 0x0000000802e27e6b
Dump of assembler code for function _ZNSo9_M_insertIdEERSoT_:
0x0000000802e27e40 <_ZNSo9_M_insertIdEERSoT_+0>:	push   %rbp
0x0000000802e27e41 <_ZNSo9_M_insertIdEERSoT_+1>:	mov    %rdi,%rsi
0x0000000802e27e44 <_ZNSo9_M_insertIdEERSoT_+4>:	mov    %rsp,%rbp
0x0000000802e27e47 <_ZNSo9_M_insertIdEERSoT_+7>:	mov    %r12,-0x18(%rbp)
0x0000000802e27e4b <_ZNSo9_M_insertIdEERSoT_+11>:	mov    %rdi,%r12
0x0000000802e27e4e <_ZNSo9_M_insertIdEERSoT_+14>:	mov    %rbx,-0x20(%rbp)
0x0000000802e27e52 <_ZNSo9_M_insertIdEERSoT_+18>:	mov    %r13,-0x10(%rbp)
0x0000000802e27e56 <_ZNSo9_M_insertIdEERSoT_+22>:	mov    %r14,-0x8(%rbp)
0x0000000802e27e5a <_ZNSo9_M_insertIdEERSoT_+26>:	sub    $0x20,%rsp
0x0000000802e27e5e <_ZNSo9_M_insertIdEERSoT_+30>:	and    $0xffffffffffffffe0,%rsp
0x0000000802e27e62 <_ZNSo9_M_insertIdEERSoT_+34>:	add    $0xffffffffffffff80,%rsp
0x0000000802e27e66 <_ZNSo9_M_insertIdEERSoT_+38>:	lea    0x50(%rsp),%rdi
0x0000000802e27e6b <_ZNSo9_M_insertIdEERSoT_+43>:	lds    (bad),%edi
0x0000000802e27e6c <_ZNSo9_M_insertIdEERSoT_+44>:	sti    
0x0000000802e27e6d <_ZNSo9_M_insertIdEERSoT_+45>:	adc    %eax,0x18(%rsp)
0x0000000802e27e71 <_ZNSo9_M_insertIdEERSoT_+49>:	callq  0x802dea0b0 <_ZNSo6sentryC1ERSo@plt>
0x0000000802e27e76 <_ZNSo9_M_insertIdEERSoT_+54>:	cmpb   $0x0,0x50(%rsp)
0x0000000802e27e7b <_ZNSo9_M_insertIdEERSoT_+59>:	je     0x802e27f13 <_ZNSo9_M_insertIdEERSoT_+211>
0x0000000802e27e81 <_ZNSo9_M_insertIdEERSoT_+65>:	mov    (%r12),%rax
0x0000000802e27e85 <_ZNSo9_M_insertIdEERSoT_+69>:	mov    %r12,%r13
0x0000000802e27e88 <_ZNSo9_M_insertIdEERSoT_+72>:	add    -0x18(%rax),%r13
0x0000000802e27e8c <_ZNSo9_M_insertIdEERSoT_+76>:	mov    0xf8(%r13),%r14
0x0000000802e27e93 <_ZNSo9_M_insertIdEERSoT_+83>:	test   %r14,%r14
0x0000000802e27e96 <_ZNSo9_M_insertIdEERSoT_+86>:	je     0x802e27fdc <_ZNSo9_M_insertIdEERSoT_+412>
0x0000000802e27e9c <_ZNSo9_M_insertIdEERSoT_+92>:	cmpb   $0x0,0xe1(%r13)
0x0000000802e27ea4 <_ZNSo9_M_insertIdEERSoT_+100>:	je     0x802e27f60 <_ZNSo9_M_insertIdEERSoT_+288>
0x0000000802e27eaa <_ZNSo9_M_insertIdEERSoT_+106>:	movzbl 0xe0(%r13),%eax
0x0000000802e27eb2 <_ZNSo9_M_insertIdEERSoT_+114>:	mov    0xe8(%r13),%rsi
0x0000000802e27eb9 <_ZNSo9_M_insertIdEERSoT_+121>:	movsbl %al,%r8d
0x0000000802e27ebd <_ZNSo9_M_insertIdEERSoT_+125>:	mov    %r13,%rcx
0x0000000802e27ec0 <_ZNSo9_M_insertIdEERSoT_+128>:	mov    (%r14),%r9
0x0000000802e27ec3 <_ZNSo9_M_insertIdEERSoT_+131>:	mov    %r14,%rdi
0x0000000802e27ec6 <_ZNSo9_M_insertIdEERSoT_+134>:	lds    (bad),%edi
0x0000000802e27ec7 <_ZNSo9_M_insertIdEERSoT_+135>:	sti    
0x0000000802e27ec8 <_ZNSo9_M_insertIdEERSoT_+136>:	adc    %al,0x18(%rsp)
0x0000000802e27ecc <_ZNSo9_M_insertIdEERSoT_+140>:	test   %rsi,%rsi
0x0000000802e27ecf <_ZNSo9_M_insertIdEERSoT_+143>:	mov    %rsi,0x60(%rsp)
```

I am running on an ASUS P8H61-M LE/USB3 - corei5-2500 with 8GB RAM with an nvidia GT520.

Blender uses cmake - default cflags for release is -O3 -DNDEBUG - I normally add -march=native -mfpmath=sse.

With gcc I have tried native and core2 for march. With gcc46 I also tried corei7. I have tried with and without march and mfpmath. I have tried -O0 -O1 -O2 -O3 and -Os - -Os generates illegal instructions that prevent the build from finishing - builds a tool to generate some source files.

Pretty sure I have tried each combination of those options. With the same code working on 8.2 I lean to it being a 9.0 change (maybe a 32/64 bit difference).

Not sure what else to try.


```
[leader:~] shane% gcc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]

[leader:~] shane% gcc46 -v
Using built-in specs.
COLLECT_GCC=gcc46
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/lto-wrapper
Target: x86_64-portbld-freebsd9.0
Configured with: ./../gcc-4.6-20111209/configure --disable-nls --enable-languages=c,c++,objc,fortran 
--libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46 --program-suffix=46 --with-as=/usr/local/bin/as 
--with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/ 
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD Ports Collection' 
--with-system-zlib --disable-libgcj --prefix=/usr/local --mandir=/usr/local/man 
--infodir=/usr/local/info/gcc46 --build=x86_64-portbld-freebsd9.0
Thread model: posix
gcc version 4.6.3 20111209 (prerelease) (FreeBSD Ports Collection)
```

Thanks.


----------



## sambler (Jan 11, 2012)

I seem to have pin pointed the problem - either math lib or std::ostringstream.

I tracked down the part of the blender code causing the issue and found that sending the result of ceil() to a std::ostringstream using the << operator is the issue.

If the ceil() is changed to ceill() it works but ceil() and ceilf() fail.

See the attached source file for testing (I just used *g++ test.cpp;./a.out*)

g++/g++46 and clang++ produce the errror.


----------

