Bug #1334

blender : Segmentation Fault (core dumped)

Added by Richard Kowalski over 3 years ago. Updated over 3 years ago.

Status:ResolvedStart date:2011-08-04
Priority:LowDue date:2011-09-03
Assignee:Alex Viskovatoff% Done:


Category:-Estimated time:8.00 hours
Target version:-
Difficulty:Medium Tags:needs-triage



  1. pkg install -v image/editor/blender
    % blender
    Segmentation Fault (core dumped)

Reproducible: Everytime

Segmentation Fault (core dumped)

Expected Result:
Blender executes without error, fault, or failure.

Further Information:
  1. pkg install -v image/editor/blender
    Packages to install: 3
    Create boot environment: No
    Rebuild boot archive: No
    Changed fmris:
    None -> pkg://openindiana.org/library/,5.11-0.151:20110523T145212Z
    None -> pkg://openindiana.org/library/,5.11-0.151:20110523T145000Z
    None -> pkg://sfebuild/image/editor/,5.11-0.151:20110730T070336Z
    Completed 3/3 363/363 10.9/10.9

Install Phase 507/507

Package State Update Phase 3/3
Image State Update Phase 2/2 #

% blender --version
Blender 2.49 (sub 2) Build

% pkgtool --version
pkgtool version 1.3.103

% head -1 /etc/release
OpenIndiana Development oi_151 X86 (powered by illumos)
% uname -rv
5.11 oi_151

blender_truss.log.xz (15 KB) Richard Kowalski, 2011-08-04 07:19 PM


#1 Updated by Alex Viskovatoff over 3 years ago

  • Assignee set to Ken Mays
  • Status changed from New to Feedback

blender runs fine for me. There's probably a missing dependency that I have installed but you don't.

Could you post the output of ldd /usr/bin/blender-bin please?

#2 Updated by Richard Kowalski over 3 years ago

% ldd /usr/bin/blender-bin
libjpeg.so.62 => /usr/lib/libjpeg.so.62
libpng14.so.14 => /usr/lib/libpng14.so.14
libIlmImf.so.6 => /usr/lib/libIlmImf.so.6
libHalf.so.6 => /usr/lib/libHalf.so.6
libIex.so.6 => /usr/lib/libIex.so.6
libIlmThread.so.6 => /usr/lib/libIlmThread.so.6
librt.so.1 => /usr/lib/librt.so.1
libz.so.1 => /usr/lib/libz.so.1
libGLU.so.1 => /usr/lib/libGLU.so.1
libGL.so.1 => /usr/lib/libGL.so.1
libXmu.so.4 => /usr/lib/libXmu.so.4
libXext.so.0 => /usr/lib/libXext.so.0
libXi.so.5 => /usr/lib/libXi.so.5
libX11.so.4 => /usr/lib/libX11.so.4
libc.so.1 => /usr/lib/libc.so.1
libm.so.2 => /usr/lib/libm.so.2
libdl.so.1 => /usr/lib/libdl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0
libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0
libCstd.so.1 => /usr/lib/libCstd.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libImath.so.6 => /usr/lib/libImath.so.6
libpthread.so.1 => /usr/lib/libpthread.so.1
libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1
libnvidia-glcore.so.1 => /usr/lib/libnvidia-glcore.so.1
libXt.so.4 => /usr/lib/libXt.so.4
libSM.so.6 => /usr/lib/libSM.so.6
libICE.so.6 => /usr/lib/libICE.so.6
libXmuu.so.1 => /usr/lib/libXmuu.so.1
libXau.so.6 => /usr/lib/libXau.so.6
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libesd.so.0 => /usr/lib/libesd.so.0
libXrandr.so.2 => /usr/lib/libXrandr.so.2
libXrender.so.1 => /usr/lib/libXrender.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0
libXevie.so.1 => /usr/lib/libXevie.so.1
libXss.so.1 => /usr/lib/libXss.so.1

% blender
Segmentation Fault (core dumped)
% mdb core
Loading modules: [ libc.so.1 libpython2.6.so.1.0 ld.so.1 ]


no process
SIGSEGV: Segmentation Fault
%cs = 0x0043 %eax = 0xf6ba0408
%ds = 0x004b %ebx = 0x088f3d20
%ss = 0x004b %ecx = 0xfe260ec0
%es = 0x004b %edx = 0x08b28c90
%fs = 0x0000 %esi = 0x08155ba8
%gs = 0x01c3 %edi = 0x08050000

%eip = 0xfebac9b1 
%ebp = 0xfefa0978
%kesp = 0x00000000

%eflags = 0x00010282
id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0

%esp = 0x08046b58
%trapno = 0xe
%err = 0x7

% blender & PID=$! && truss -o ./blender_truss.log -S segv,bus -p ${PID}

#3 Updated by Alex Viskovatoff over 3 years ago

No missing dependency, then.

If you run "dbx /usr/bin/blender-bin core", you should be able to get a backtrace by entering "where" at the dbx command prompt. That could prove informative. (dbx comes with Sun Studio.) Or you can probably get a backtrace with gdb, too.

#4 Updated by Richard Kowalski over 3 years ago

% pflags core
core 'core' of 1628: blender-bin -w
data model = _ILP32 flags = MSACCT|MSFORK
/1: flags = 0
sigmask = 0xfffffeff,0xffffffff,0x000000ff
cursig = SIGSEGV


% dbx /usr/bin/blender-bin core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
Reading blender-bin
core file header read successfully
Reading ld.so.1
Reading libjpeg.so.62.0.0
Reading libpng14.so.14.3.0
Reading libIlmImf.so.6.0.0
Reading libHalf.so.6.0.0
Reading libIex.so.6.0.0
Reading libIlmThread.so.6.0.0
Reading librt.so.1
Reading libz.so.1
Reading libGLU.so.1
Reading libGL.so.1
Reading libXmu.so.4
Reading libXext.so.0
Reading libXi.so.5
Reading libX11.so.4
Reading libc.so.1
Reading libm.so.2
Reading libdl.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libSDL-1.2.so.0.11.2
Reading libpython2.6.so.1.0
Reading libCstd.so.1
Reading libCrun.so.1
Reading libImath.so.6.0.0
Reading libpthread.so.1
Reading libnvidia-tls.so.1
Reading libnvidia-glcore.so.1
Reading libXt.so.4
Reading libXau.so.6
t@1 (l@1) program terminated by signal SEGV (access to address exceeded protections)
0xfebac9b1: movl %eax,(%esi)
(dbx) where
current thread: t@1
[1] 0xfebac9b1(0x8155ba8, 0x2c6eb, 0x8155bb0, 0xfefa0978, 0x7, 0x387), at 0xfebac9b1
[2] 0xfebad5b2(0x88f7084, 0xfef40018, 0x0, 0x0, 0xfef8000d, 0x8050000), at 0xfebad5b2

#5 Updated by Richard Kowalski over 3 years ago

% gdb /usr/bin/blender-bin core
GNU gdb 6.8


Core was generated by `blender-bin -w'.
Program terminated with signal 11, Segmentation fault.
[New process 67164 ]
#0 0xfebac9b1 in ?? () from /usr/lib/libGL.so.1
(gdb) backtrace
#0 0xfebac9b1 in ?? () from /usr/lib/libGL.so.1
#1 0xfefa0978 in ?? ()
#2 0x08155ba8 in ?? ()
#3 0x0002c6eb in ?? ()
#4 0x08155bb0 in ?? ()
#5 0xfefa0978 in ?? ()
#6 0x00000007 in ?? ()
#7 0x00000387 in ?? ()
#8 0xfebad5b2 in ?? () from /usr/lib/libGL.so.1
#9 0x08155ba8 in ?? ()
#10 0x00000014 in ?? ()
#11 0xfebd5040 in ?? () from /usr/lib/libGL.so.1
#12 0x08ae98d8 in ?? ()
#13 0x00000000 in ?? ()

#6 Updated by Ken Mays over 3 years ago

  • Priority changed from Normal to Low
  • Due date set to 2011-09-03
  • % Done changed from 0 to 90
  • Estimated time set to 8.00

Hi Richard,
What machine are you running blender on?

Use this package for review:

#7 Updated by Ken Mays over 3 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Fixed in spec.

#8 Updated by Geoff Weiss over 3 years ago

  • Status changed from Resolved to Feedback

blender in SFE repo using oi151 and nVidia video still has the problem as reported by Richard (I can reproduce the same results with gdb). blender within a VirtualBox guest running oi151 (3D enabled and guest additions installed) does not exhibit any crashing.

The crashing occurred no matter which nVidia driver was being included with the different oi151 dev-ils (I no longer recall all the variants that were being distributed).

Running `truss blender` results in no crashes.

And running `LD_PRELOAD=libumem.so.1 blender` results in no crashes.

#9 Updated by Alex Viskovatoff over 3 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Ken Mays to Alex Viskovatoff

Since Geoff reported that running blender with LD_PRELOAD=libumem results in no crashes, I rebuilt it with -lumem, and Geoff confirmed that the new build does not crash.

Spec in SFE and package in oi-sfe updated.

Also available in: Atom PDF