Cool VL Viewer forum

Hi Henry, I have gotten sporadic crashes since a few weeks with the stable branch viewer.

I can't say exactly since when, but it was somewhere around 1.26.4.3* I think. Definitively including both 34 and the fixed 35. Funny though, it's been rock stable a month back or so.

Also, there is an issue with some icons that doesn't appear in the viewer file dialogs any more.

Tonight I ran from a console and could see that we are at this point:


FYI the icon is located at /usr/share/icons/oxygen/16x16/actions/edit-find.png (same as in the error, just single slashed) and looks just fine in all other programs as far as I can see.

List of affected files:

• edit-find.png
• dialog-cancel.png
• document-save.png
• list-add.png
• edit-delete.png

Now, the viewer crashes on me when opening a file dialogue, but not every time and not in a reproducible manner unfortunately. It just happens when a great snapshot opportunity seems to come around

Running from within a console shows that it writes a stack trace, but there is no stack_trace.log written on disk. Nor is the error_maker.

I'm not good at tracing crashes and I haven't been able to find a correlation to time spent online, memory usage, time of day or similar, and with no stack_trace.log written it's hard to find out more without a bit of help here.

Any ideas?
Would it help if I reverted back a bunch of versions to see if I can find where the icons disappeared?
Or do you think it's not related to that issue at all?
How can I get a backtrace on the crash when the viewer doesn't save anything?
And oh yeah, Debian stable here so not the newest system libs in case that matters.
I have this funny feeling this will be one of these "learning moments" somehow again

Obviously, the crash is caused by gdk-pixbuf loader (which is one of the many component of GTK+), not by the viewer...

Check what updates occurred on your system since the crash appeared (look into GTK+ conponents, or possibly libpng since these are PNG files) and you will find the culprit (a buggy library, most probably).

The way to trace a crash is described in the rules for this forum....

My very embarrassed apologies for missing the sticky instructions *facepalms*

But that was the info I was hoping to get help with finding. I'll get back if/when I can get a decent trace.

I'm confused right now

The sporadic crashes mostly happens when I take a snapshot and are about to save the file that I crash.
But I tried for a few hours this afternoon without success. (If you can call it that when you don't crash...)
Then later tonight It was immediate crashing doing the same thing.

OK, so I tried to figure over differences, and one thing came to mind which was particle sources.
Yesterday and today I was close to a particle source when crashing on saving a snapshot, but earlier I was not near one.
Would that make crashing reproducible?
So i tried a snapshot near particle source and crashed.
I then restarted the computer in case it was something that had to do with it being on for hours, but no change in behaviour.
Still crashing.
Then I turned off the particles, and no crash.

So then I thought, is this reproducible? And no... it's not. Turning particles on again did not make me crash.
So it's still way to random for my taste, and for being reliably reproducible

Attached are two logs (I hope they have everything needed now), that happened when I was trying to save a snapshot to disk. (Both comes from before the restart.)

I'll update if I find something that can pinpoint this issue, unless you have any ideas from the logs.

No updates to anything GTK or PNG related on the OS. Only Kernel, basefiles, libtiff and libc that would affect the system in general.

What version of the viewer are you using (please, provide the full SecondLife.log like required in the rules !) ?... It looks like you are using the version that had the aligned memory bug and that has since be fixed. If so, please update !

Meh, I thought I had uploaded everything... apparently I can't read.

Attaching two fresh crashlogs from gdb + secondlife.log corresponding to the first one.
I have just logged on, taken a snapshot (ctrl-shift-s) and crashed on the save file dialogue.
First time as soon as dialogue opens, last time just as it had closed.
(I'm not sure, but at the moment it seems more likely that a crash happens if the camera is aimed so that a particle source is in "what you see", but it is not reliably reproducible.)

About viewer says:


Any more info I can share to help?

I downloaded 1.26.5.15 and it seems that version doesn't show any gdk/gtk errors in the console even if the graphics is still missing in the file dialogue.

Too early to say if 1.26.5.15 is more stable as the crashes isn't reliably reproducible, but I'll report if that branch is affected or not after a bit of mileage with it.

Btw, do you think it would be a good idea to reinstall the 1.26.4 version of the viewer?
(Oh and before you ask, I run 1.26.5.15 with a separate cache)

From the logs, it is obvious that the crash occurs in one of the many GTK+ components libraries and not in the viewer code itself (it's a GTK+ bug). I can do nothing for you, I'm afraid; as I already suggested, check for which updates made their way to your system (if any GTK+ related update occurred, just revert back to the previous version and the crash will likely go away).

Thanks for the help, no GTK-related updates has taken place though. (At least nothing with GTK or GDK in the name!)

I saw Amalia Illios message about file dialogue related issues with the non-tcmalloc viewer version in the feedback for render 3.3 thread, and as I crash with 1.26.5.16 as well tonight (hanged that bad I couldn't even get a backtrace out) I've reverted down to last tcmalloc-enabled version of your viewer (1.24.6.32) now just in the rare case I face something similar like she did here.

I'll let you know if I find anything out.

It's not a tcmalloc(-less) issue (see the stack trace...), so I doubt very much that downgrading to 1.24.6.32 will do any difference.