[Bf-committers] crash while changing subsurf properties

Campbell Barton cbarton at metavr.com
Fri Jan 13 04:03:45 CET 2006


just got the same bug. Improting a UV-Mapped OBJ file and thaught it was 
the iported. But tested a blender from a bonth ago and no problems. Will 
commit my ob

Matthew Fulmer wrote:
> This happened when I pressed the [Subsurf UV] button under the
> subsurf modifier:
>
> $ gdb ./blender
> GNU gdb 6.4
> Copyright 2005 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
>
> (gdb) r
> Starting program: /home/tapple/cabbage/blender/blender/blender
> [Thread debugging using libthread_db enabled]
> [New Thread -1224517920 (LWP 12617)]
> Using Python version 2.4
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1224517920 (LWP 12617)]
> 0x084b505d in ss_sync_from_uv (ss=0x8da96c8, origss=0x8d68938,
>     me=0x8e1c5a0, dlm=0x0) at subsurf_ccg.c:286
> 286                     for (v=get_uv_map_vert(vmap, i)->next; v; v=v->next)
> (gdb) print v
> $1 = (UvMapVert *) 0x0
> (gdb) print vmap
> $2 = (UvVertMap *) 0x8cc7b40
> (gdb) print i
> $3 = 51
> (gdb) bt
> #0  0x084b505d in ss_sync_from_uv (ss=0x8da96c8, origss=0x8d68938,
>     me=0x8e1c5a0, dlm=0x0) at subsurf_ccg.c:286
> #1  0x084b59e8 in ss_to_displistmesh (ss=0x8d68938, ccgdm=0x0,
>     ssFromEditmesh=0, drawInteriorEdges=1, useSubsurfUv=8,
>     inMe=0x8e1c5a0, inDLM=0x0) at subsurf_ccg.c:485
> #2  0x084ba6a6 in subsurf_make_derived_from_mesh (me=0x8e1c5a0,
>     dlm=0x0, smd=0x8e1c530, useRenderParams=0, vertCos=0x0,
>     isFinalCalc=1) at subsurf_ccg.c:1757
> #3  0x08488935 in subsurfModifier_applyModifier (md=0x8e1c530,
>     ob=0x8e1c1b8, derivedData=0x0, vertexCos=0x0, useRenderParams=0,
>     isFinalCalc=1) at modifier.c:198
> #4  0x0846ee75 in mesh_calc_modifiers (ob=0x8e1c1b8,
>     inputVertexCos=0x0, deform_r=0x8e1c4a4, final_r=0x8e1c4a8,
>     useRenderParams=0, useDeform=1) at DerivedMesh.c:1566
> #5  0x0846f961 in mesh_build_data (ob=0x8e1c1b8)
>     at DerivedMesh.c:1844
> #6  0x0846faf0 in makeDispListMesh (ob=0x8e1c1b8)
>     at DerivedMesh.c:1888
> #7  0x084a95b8 in object_handle_update (ob=0x8e1c1b8)
>     at object.c:1817
> #8  0x081e8b49 in drawview3dspace (sa=0x8dd88e8, spacedata=0x8dd8b80)
>     at drawview.c:2236
> #9  0x082c6dca in scrarea_do_windraw (area=0x8dd88e8)
>     at spacetypes.c:113
> #10 0x08214054 in scrarea_dispatch_events (sa=0x8dd88e8)
>     at editscreen.c:579
> #11 0x0821530b in screen_dispatch_events () at editscreen.c:1150
> #12 0x08215acd in screenmain () at editscreen.c:1401
> #13 0x081dda29 in main (argc=1, argv=0xbf8e1904) at creator.c:592
> (gdb)
>
> It looks like the v node was null and got dereferenced in
> v->next. The offending blend file is at 
>
> http://www.public.asu.edu/~mtfulmer/uvbug.blend
>
> to reproduce:
>
> open the provided file in the latest cvs bf-blender
> press the Subsurf UV button in the Modifiers pane
>
> system information:
>
> Gentoo Linux
> gcc 3.4.5
> i386: Pentium 4
> scons build
> latest cvs of HEAD
>
>   


-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241


More information about the Bf-committers mailing list