Hi, I tested the file and can't redo the crash but not for all that long (1 min or so)

GeForce 8800 GTS, Ubuntu 12.04 64bit here.

Also ran the script and tested with valgrind with no warnings of bad memory use.

I found a way to reproduce the bug much more reliably (by chance). Open the attached TwoBoneMesh.blend file. Click on the green axis to move the armature about one square to the right. Select Object Mode. Right click on the smaller armature that was hidden by the larger one. WIth this method, i get the seg fault about 8 out of 10 times on the first click to select the small armature. Also attached, a screen recording of the steps.

kesten

Seconded on this one. I'm using Linux Mint 11 (Katya) which is Ubuntu based.
I'm using this on an old laptop with a Dual Core Intel T2310 - 1.46GHz, 2GB Ram and running on 64Bit.
I've had very few problems with it and Linux has proved more reliable and compatible than Windows 7.

Simply opening Blenrig_gilgamesh and right clicking on any of the bones in pose mode will "Warp to Desktop" with a segmentation fault.
I thought originally it was something to do with my own rig which is why I tried this third party one.

Under GDB I get this.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe66b1924 in ?? () from /usr/lib/dri/libdricore.so

Stack backtrace...
#0 0x00007fffe66b1924 in ?? () from /usr/lib/dri/libdricore.so
#1 0x00007fffe66aebea in _tnl_run_pipeline () from /usr/lib/dri/libdricore.so
#2 0x00007fffe66afabc in _tnl_draw_prims () from /usr/lib/dri/libdricore.so
#3 0x00007fffe66afde6 in _tnl_vbo_draw_prims () from /usr/lib/dri/libdricore.so
#4 0x00007fffe66a5e92 in vbo_rebase_prims () from /usr/lib/dri/libdricore.so
#5 0x00007fffe66af93b in _tnl_draw_prims () from /usr/lib/dri/libdricore.so
#6 0x00007fffe6a1dd54 in brw_draw_prims () from /usr/lib/dri/i965_dri.so
#7 0x00007fffe66a3deb in ?? () from /usr/lib/dri/libdricore.so
#8 0x00007fffe66a3f46 in ?? () from /usr/lib/dri/libdricore.so
#9 0x0000000000f15aaf in ?? ()
#10 0x0000000000bea689 in draw_object_instance ()
#11 0x0000000000bf37cc in ?? ()
#12 0x0000000000bf4b66 in draw_armature ()
#13 0x0000000000be98f4 in draw_object ()
#14 0x0000000000bd75b3 in view3d_opengl_select ()
#15 0x0000000000bcc0fe in ?? ()
#16 0x0000000000bcdd19 in ?? ()
#17 0x0000000000bce35f in ?? ()
#18 0x0000000000b21c1d in ?? ()
#19 0x0000000000b22bd5 in ?? ()
#20 0x0000000000b22e66 in ?? ()
#21 0x0000000000b23995 in wm_event_do_handlers ()
#22 0x0000000000b1ece8 in WM_main ()
#23 0x0000000000b1e483 in main ()

So off the top of my head I would say it's something to do with a rogue pointer in draw_object_instance() when it calls the OpenGL dri library.

Maybe I should start compiling a version with debug symbols in and do a proper trace of what's going on but after deciding on changing careers to that of a 3d Modeller in January I'm somewhat reluctant to dust off my old programming skills.

Although I do need a job. Hint, Hint ;-)

Well that was an interesting couple of hours downloading source, compiling and investigating. I thought I'd do it anyway as it's an opportunity to get familiar with the blender codebase.

The quick fix is to go to user preferences/system and disable one little tick box with the word 'VBOs' next to it. *Simples*

Line 411 of ccderivedmesh.c function cdDM_drawEdges() has an if statement that chooses between Vertex Buffer rendering or Legacy Mode. Rendering will be a little slower but it won't crash.

My little laptop has an Intel GMA video adaptor which has been twitchy with VBOs in the past on other programs so it's probably something to do with the OpenGL implementation rather than blender itself but I'll investigate a little further for another hour or so to see if a fix can be made.

I looked a bit closer and it seems to be something to do with the derived mesh functions.

Line 7408 of drawobject.c function draw_object_mesh_instance() calls mesh_get_derived_final() on line 2184 of DerivedMesh.c which in turn calls mesh_build_data() on line 2118 which in turn calls mesh_calc_modifiers() on line 1353. Then I got a headache trying to work out what this positively huge function is doing to screw up the returned derived mesh which is causing the segfault when we finally get to the call to glDrawElements() on line 1255 of gpu_buffers.c

anyway line 1794 of file DerivedMesh.c has this on it.

/* Need to watch this, it can cause issues, see bug [#29338] */
/* take care with this block, we really need testing frameworks */
/* --------------------------------------------------------------------- */

Can't find bug #29338 on the bug tracker anywhere to see if it's relevant.

That's as deep as I'm going my head hurts from rapidly trying to pick up the program structure. Which isn't too bad actually.
It's certainly not the nightmare of the source code to the second life viewer which I've also had dealings with in the past when I tried to make it import morphs so my custom AVs could blink.
I gave up in the end and decided someone else with better knowledge of OpenGL should do it eventually as it's not really in my vast repertoire of knowledge.
Ask me about ternary trie databases and hash tables and I'm a fount of wisdom however. ;-)

Moved from Blender 2.6 Bug Tracker to OpenGL errors

Well, it seems to completely be an OpenGL issue which is easy to notice from a backtrace. We had this issue several times already with intel drivers and that was fixed with newer mesa/intel drivers on linux. Probably something the same happens with ATI drivers.

The problem here is that place of crash and place of actual opengl instruction which causes crash are completely different. Can only mention that there were several changes to how OpenGL is used which might in theory resolve this issue.

Meanwhile moving to OpenGL tracker where we hopefully find a developer with the same issue and who could figure out what exactly causes the crash,

Closed likely the same issue http://projects.blender.org/tracker/index.php?func=detail&aid=32007&group_id=9&atid=498