Cool VL Viewer forum

Hi Henri,

you wrote:If I have rare (i.e. < 3 per week) 'semi-random' crashes, where I can't specifically reproduce the crash with the exact details, I no longer bother to post about it unless someone else observes something similar -- mainly because I can't provide all the details you (rightfully) insist upon.

Once someone else makes a similar observation, I see a point in trying to exchange information as to possibly find the way to reproduce the issue. That way, you do finally get all you need.

Love,
Lia

That's a whole lot of crashes !... It takes a full month for me to reach the same number (3)... I need people to report crashes (and yes, to report them properly with all the necessary info) to hunt down those bugs I never come across myself (be it either because I use a different hardware and drivers, or because I simply don't use the features of the viewer where the crashes happen).

Hi Henri et al.,

well, first editing crash of the month. Mind you, it was a simple plywood cube, albeit physical.

Love,
Lia

P.S.: Make that two. Plywood box, this time flexi.

That's really amazing, because I can look at the code again and again, and I see no possible crash in LLOctreeIntersect::check(LLDrawable* drawable): all exceptions have been plugged already... I also found similar crash reports for the official viewer v3.3 (see VWR-28372 and all the related issues), and Lindens seem as clueless as I am, since they didn't come up with a fix as of yet.

The only way I could find what's going wrong in that apparently flawless piece of code, would be to reproduce the crash myself while under a gdb session. To achieve this, we'd need some reliable repro steps. Also the JIRA seems to give one common point to these crashes: they seem to happen when you try editing while wearing rigged meshes (I myself tried, wearing a custom petite avatar and other rigged meshes, but to no avail so far). Could you please describe exactly what your avatar is wearing and what exact actions you were performing when these crash happened ("editing" is quite a bit vague: what kind of editing: size, position, rotation ?... Did it happen while editing a linkset or a single prim ? What mouse action triggered the crash: a click on the prim, on the edit handles, a drag ?...).

Hi Henri,

you wrote:Hmmmm, interesting wrinkle, that. I most certainly can add a +1 to the "while wearing rigged mesh" theory. Today I was wearing Bellona boots as well as the Hello Spacegirl corset and neck corset. On at least one other occasion I also know I was wearing a mesh dress.See above; please let me know if you need to know about the non-mesh parts as well.From what I can tell, there is nothing specific. In today's cases, the flexi was being dragged by the xy handle, whereas the physical was being resized with the x handle. I've had one more crash where I hadn't even done anything yet, merely hit the "Build" button and then clicked in-world to rez the prim. I didn't even get to see the box materialize anymore -- I crashed right away. Stack trace confirmed it was most likely the same bug.

So it doesn't really seem to matter what you do to the prim/object. Just the fact that it's there and being edited seems to be enough. I presume it may have to do with the yellow/blue highlighting or somesuch.

I'm open to any other suggestions and willing to try stuff. However, I've rolled back to .15 for now to do "real work", because it seems to be a bit more stable, at least subjectively.

Love,
Lia

Not only is it completely subjective, but 1.26.4.16 *does* cure bugs that existed in 1.26.4.15, and it didn't introduce any new bug either.

Another question that just came to my mind is: where are you doing the editing when you crash, and more accurately, what kind of "floor" are you editing the primitives on (sim ground, normal primitive, mega-prim, sculpty, mesh prim, convex hull prim or not) ? Also, are you wearing HUD(s) that would be partly transparent (an thus that would result in the pointer "hit" to be passed from the HUD to the in-world object by the viewer) ?

Hi Henri,

you wrote:While I have no reason to doubt you, I didn't crash after switching back, and it was a session that lasted a couple of hours, whereas with .16 I would last 15 minutes of editing at best earlier, while none of the other parameters have changed. I do realize that it quite possibly is coincidental, though.Regular prim as well as sim ground. Nothing fancy there at all.That might be something worth investigating. I do tend to travel light as far as HUDs go, but there is some transparency involved. I'll check and report back if I observe anything noteworthy.

Love,
Lia

Hi Henri,

https://jira.secondlife.com/browse/VWR-28372 proclaims to be fixed and might be related. I was wondering if that fix is already part of 1.26.5.2. Just crashed again earlier today in the usual pattern (i.e. starting to edit), while wearing some Jaimie Earst mesh boots and skirt filler.

Love,
Lia

Yes, it is, but I doubt very much the said "fix" is related to the crash you just got...

Alas, while I can reproduces crashes here, from time to time, I cannot get gdb to produce a useful stacktrace (it gets stuck in a "File /usr/share/glib-2.0/gdb/gobject.py, line 45, in is_g_type_instance_helper return is_g_type_instance_helper(first_field.type)" loop that seems to be a bug in gdb itself !). If you can get a proper stacktrace from gdb that would show the actual line where the crash happens, it would help immensely...

I just uploaded the symbols file for v1.26.5.2, and you can get it from here (86Mb, compressed !). Once downloaded, bunzip it and place it inside the bin/ sub-directory of the v1.26.5.2's installation directory, then change (cd) to the latter directory and type: ./cool_vl_viewer --debug

Hi Henri,

thank you for providing the means to hunt this down. I'm running with --debug right now, hoping for the issue to manifest itself. I'll give a holler once it does!

Love,
Lia