[Bf-committers] Interesting 2.33a crash bug on Mac

Richard Berry bf-committers@blender.org
Wed, 09 Jun 2004 14:47:16 +0100


And by interesting I mean sporadic and not exactly reproducible... let the =
games begin. Firstly, I've only got access to a Mac PowerBook so I don't =
know how it affects other Macs or if the problem exists on other architectu=
res. Secondly, it affects 2.33a and possibly also the current CVS but I've =
had less success getting reproducible results with CVS builds.

The system that I'm using a 15" PowerBook with ATI Mobility 9600 with Mac =
OS X 10.3.3 (but the problem still happens with 10.3.4).



To reproduce the problem get the following file (used to be on Blenderman =
but they've had their bandwidth hosed):

http://www.katorlegaz.com/models/computers/imac-2002.blend.zip



If it loads correctly, congratulations, otherwise it might do one of the =
following things:
1) crash, with the usual Mac OS X popup explaining that the app has =
crashed and would you like to send a bug report to Apple, etc.
2) freeze your system,
3) freeze your system and corrupt your screen, or
4) cause Mac OS X to show the "please hold down the power button to =
restart your system" screen.

i.e. not good.

What mainly concerns me are 2, 3 and 4, but as these are system crashes it =
probably means that it's an OS X problem given that no matter what bizarre =
stuff Blender does it shouldn't be able to crash the system.



Debugging this has been a bit of a pain because the problem isn't exactly =
reproducible. With newer CVS builds the problem sometimes doesn't occur at =
all. Below are two GDB sessions where it crashed (these are from a debug =
build that I made with the 2.33a source but the problem still occurs for =
the 2.33a distribution binary):



Program received signal EXC_BAD_ACCESS, Could not access memory.
0x040f4c54 in ?? ()
(gdb) bt
#0  0x040f4c54 in ?? ()
#1  0x0010e020 in drawmeshsolid (ob=3D0x414a21c, nors=3D0x62d9c94) at =
source/blender/src/drawobject.c:1889
#2  0x00113674 in draw_object (base=3D0x2b89e3c) at source/blender/src/draw=
object.c:3618
#3  0x0011b268 in drawview3dspace (sa=3D0x2b851fc, spacedata=3D0x414761c) =
at source/blender/src/drawview.c:1778
#4  0x00216fcc in scrarea_do_windraw (area=3D0x2b851fc) at source/blender/s=
rc/spacetypes.c:109
#5  0x000297c8 in scrarea_dispatch_events (sa=3D0x2b851fc) at source/blende=
r/src/editscreen.c:537
#6  0x0002aa88 in screen_dispatch_events () at source/blender/src/editscree=
n.c:897
#7  0x0002b5a8 in screenmain () at source/blender/src/editscreen.c:1120
#8  0x00004110 in main (argc=3D1, argv=3D0xbffffcb8) at source/creator/crea=
tor.c:576
(gdb)



Program received signal EXC_BAD_ACCESS, Could not access memory.
0x05f3d9e0 in qh_qhstat ()
(gdb) bt
#0  0x05f3d9e0 in qh_qhstat ()
#1  0x05f3dab4 in qh_qhstat ()
#2  0x05f5a780 in qh_qhstat ()
#3  0x05ec1260 in qh_qhstat ()
#4  0x0010e0b0 in drawmeshsolid (ob=3DCannot access memory at address =
0x3ec3fe0e
) at source/blender/src/drawobject.c:1902
#5  0x0010eadc in drawDispList (ob=3D0x415161c, dt=3D3) at source/blender/s=
rc/drawobject.c:2085
#6  0x00113674 in draw_object (base=3D0x2b88b4c) at source/blender/src/draw=
object.c:3618
#7  0x0011b268 in drawview3dspace (sa=3D0x2b83f0c, spacedata=3D0x414ea1c) =
at source/blender/src/drawview.c:1778
#8  0x00216fcc in scrarea_do_windraw (area=3D0x2b83f0c) at source/blender/s=
rc/spacetypes.c:109
#9  0x000297c8 in scrarea_dispatch_events (sa=3D0x2b83f0c) at source/blende=
r/src/editscreen.c:537
#10 0x0002aa88 in screen_dispatch_events () at source/blender/src/editscree=
n.c:897
#11 0x0002b5a8 in screenmain () at source/blender/src/editscreen.c:1120
#12 0x00004110 in main (argc=3D1, argv=3D0xbffffcb8) at source/creator/crea=
tor.c:576
(gdb)



In the first one, line 1889 is a call to glVertex3fv. In the second one, =
line 1902 is a call to glEnd. That's apart from the fact that GDB says =
drawmeshsolid is passed an invalid Object pointer...

I'm assuming that these crashes are happening because Blender passes =
incorrect pointers or invalid data to OpenGL, which then dies once it =
dereferences them. Is there any sort of debug util for the Blender file =
format that I can use to check the file (short of putting lots of printf =
statements in to do it myself, not fun)? I assume that Blender does =
appropriate checks for validating input data so that a corrupt file (e.g. =
incorrect array sizes) would get noticed when loading...?

r i c k