Page MenuHome

Array modifier segfaults with UV Spheres and cylinders
Closed, ArchivedPublicKNOWN ISSUE

Description

On my system (Ubuntu 7.10), using an array modifier with "count">2 causes blender to crash when the object is a sphere or a cylinder.

This bug is present with both v.2.46 (binary package) and the current SVN revision (15190). It only happens with UV spheres and cylinders. It seems to occur randomly, since the "count" value where it occurs is not always the same (between 3 and 12). The only message on the console is "Segmentation fault".

Event Timeline

This bug only seems to append in "solid" mode. Still, if I go back to solid mode and the array is present, Blender crashes at once. (tested on rev. 15258)
Bizarre...

Hi, I can't reproduce this with the latest SVN. Can you confirm whether you're still experiencing the problem?

Yes, I just reproduced it today with rev. 15978 and the same file. Array modifier -> click "count" -> crash ! Very annoying.
I just noticed that the bug also happens with v.2.45. It might be caused by my system, as I use a realtime patched kernel. I will try as soon as possible with the normal kernel to verify.
I have no clue about what causes this.

1)Thanks Ben.

As I am not a coder (I only know some very basic concepts), I can only "witness" the symptoms and make some vague hypotheses.
Please tell me if I can do something to describe the bug more precisely.

2) If the bug only happens on some platforms, here is what hardware I use :
- P4 "northwood" 2 GHz
- ATI Radeon 7500
- 1024 MB Ram.
My OS is Ubuntu Gutsy (7.10)

3) Some news :

- the bug has nothing to do with the real-time kernel, anyway that idea didn't make much sense.

- The bug doesn't seem to happen (anymore) with cylinders. Only spheres. (Can somebody change the bug's decription ?)

- I also noticed that the bug only happens in solid view. If I use any "bad" value in another view mode, there is no crash, but Blender crashes when I return to the 'solid' mode in the 3D view.

- I tried something very empyric. I used all values between
2 to 132 with two different UV spheres (32x32, 16x16)
* 32x32 sphere, radius 1 :
Values that crash Blender :3, 5, 9, 11, 15, 21, 24, 30, 34, 36, 38, 40, 44, 46, 48, 50, 52, 60, 68, 70, 72,
74, 76, 80, 82, 84, 86, 88, 90, 92, 94, 98, 100, 102, 104, 108, 110, 114, 116, 118, 122, 132.
* 16x16 sphere, radius 1 : 5, 9, 17, 19, 21 to 23, 25, 27, 29, 31, 33 to 35, 37 to 39, 41, 42, 46, 50, 58, 62, 78, 84, 86, 90, 92, 94, 96, 100, 102, 106, 112, 114, 116, 122, 124, 128, 130.
* The sphere's radius doesn't seem to have any influence on this.

You may smile at my method. My conclusion is not a lot better, but I'll be glad if it helps solving the bug.

I have several hypotheses :
- When the array modifier is given some specific parameters, related to the UV Sphere's data, the returned result is incorrect.
- Or this result is correct, but for some reason, it triggers a bug in the function that renders faces in the solid mode.
- Or this function is correct, but it triggers a bug in some graphic cards' drivers.

I hope this helps somehow.
Anyway, please forgive my poor English and my lack of technical skills.

I confirm the bug is not directly related to the array modifier.

I have got other similar crashes with blender, only in solid mode, with various other models than my example, some of them did not use any array modifier.

I have recompiled mesa-3d with the latest version, its debugging option doesn't see any problem.

But I have run Blender with gdb and the segmentation fault seems to happen in vbo_split_inplace.c, which is part of mesa3d, not blender.

So either Blender is absolutely innocent, and mesa3d has a bug on my graphics card, or blender tries to use a bugged feature in mesa3d.

-------------------------------------------------------
I am far beyond my competences, so I think I am not going to post any more comments in this tracker.

In case someone experiences the same problem, I still post what I got from gdb with blender rev. 16330 :

----------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219164480 (LWP 27591)]
0xb73dc83e in vbo_split_inplace (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f374, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14f228)
at vbo/vbo_split_inplace.c:268

268 {
(gdb) where
#0 0xb73dc83e in vbo_split_inplace (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f374, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14f228)
at vbo/vbo_split_inplace.c:268
#1 0xb73db8e2 in vbo_split_prims (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f374, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14f228) at vbo/vbo_split.c:152
#2 0xb732d7e5 in _tnl_draw_prims (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f374, nr_prims=7, ib=0x0,
min_index=0, max_index=912) at tnl/t_draw.c:383
#3 0xb73dc7d0 in flush_vertex (split=0xbf14f350) at vbo/vbo_split_inplace.c:99
#4 0xb73dcc70 in vbo_split_inplace (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f774, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14f628)
at vbo/vbo_split_inplace.c:255
#5 0xb73db8e2 in vbo_split_prims (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f774, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14f228) at vbo/vbo_split.c:152
#6 0xb732d7e5 in _tnl_draw_prims (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14f774, nr_prims=7, ib=0x0,
min_index=0, max_index=912) at tnl/t_draw.c:383
#7 0xb73dc7d0 in flush_vertex (split=0xbf14f750) at vbo/vbo_split_inplace.c:99
#8 0xb73dcc70 in vbo_split_inplace (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14fb74, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14fa28)
at vbo/vbo_split_inplace.c:255
#9 0xb73db8e2 in vbo_split_prims (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14fb74, nr_prims=7, ib=0x0,
min_index=0, max_index=912, draw=0xb732d705 <_tnl_draw_prims>, limits=0xbf14f228) at vbo/vbo_split.c:152
#10 0xb732d7e5 in _tnl_draw_prims (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14fb74, nr_prims=7, ib=0x0,
min_index=0, max_index=912) at tnl/t_draw.c:383
#11 0xb73dc7d0 in flush_vertex (split=0xbf14fb50) at vbo/vbo_split_inplace.c:99
#12 0xb73dcc70 in vbo_split_inplace (ctx=0x964b930, arrays=0xbf94aaec, prim=0xbf14ff74, nr_prims=7, ib=0x0,
---Type <return> to continue, or q <return> to quit---

-----------------------------------------
When I type <return>, the log continues with the same thing.

(I have followed the advices in http://blenderartists.org/forum/showthread.php?t=62749)

I hope I didn't took too much of your time.

Test file works fine here (OSX PPC). The backtrace clearly shows an opengl error.
You might consider changing graphics drivers, and try this on another computer to verify!

Thank you Ton !
After some research I have learned that the free drivers for ATI cards on GNU/Linux often crash.
I will use the static version until I change my graphics card.


I just tried Blender 2.47 in Windows on the same computer. Everything works perfectly. Then I can confirm that the bug is in the graphic driver, not in Blender.

Thank you Ton and Ben. Sorry if I wasted your time.

This is a generic request to test your bug report and see if it is still an issue in 2.5alpha2 if so please let me know by making a comment in this report ie 'also in 2.5alpha2' and I will add it to the 2.5 bug list.

Matt Ebb (broken) changed the task status from Unknown Status to Unknown Status.Mar 26 2010, 6:38 AM