Cool VL Viewer forum

This morning, Cool VL Viewer v1.30.2.3 crashed when trying to change specular texture settings on a single-prim object my avatar was wearing at the time. I have attached the SL and crash logs.

I was able to make the texture change by taking off the item, rezzing it in-world, editing it, and taking it back into Inventory, but something very strange happened when I did - the object's permissions changed:

Incidentally, don't blame me for the object name...

Thank you !

It looks like the viewer entered an infinite, recursive loop and exhausted the stack memory... Sadly, given the "infinite" aspect, the stack trace does not list the call that triggered it in the first place, but just the 512 last function calls for the repetitions of that loop.

Beside, I am unable to reproduce the crash here by applying a specular map to an attached prim for a standard attachment.

Was it a rigged attachment ? Also, does the bug get triggered when changing the diffuse or normal maps as well ?

Could you please reproduce this bug, by first enabling the "Materials" debug tag ("Advanced" -> "Consoles" -> "Debug tags"), and post the resulting log/stack trace, so that we can (hopefully) see the trace of the call that triggers this bug in the viewer log (that may become enormous as a result: if it gets too big to post, just truncate it after the point where the infinite repetition starts) ?

This is not a viewer issue, but just a limitation (and bug for no-mod assets) of SL's permissions system: the container inherits the strictest permissions of the contained assets when you take it back to your inventory. Obviously, the maker of that object changed its permissions from their own inventory (only the creator can do that, unless the object is already full perm), but failed to verify that the contained assets do bear the same permissions. The result is that when the next owner rezzes that object and takes it back to their inventory, the permissions change...

This limitation makes sense for no-copy and no-tfr assets (and here, it's the creator responsibility for keeping the coherency between the assets and container permissions), but this is a very annoying bug for no-mod (closed sources) scripts; as a creator, when you want your scripts to be kept as closed sources, but wish to make the object containing them mod-ok for the final user, you can make the object mod-ok in-world, but it nonetheless gets flagged no-mod when taking it back to your inventory, because of the no-mod scripts. As the creator, you can make it mod-ok again in your inventory, but once you give or sell it, the final owner will be faced with the same permissions change issue when rezzing it and taking it back, and won't be able to make the modified object mod-ok again in their own inventory (meaning they won't be able to rename it any more in their inventory, neither change its description from there, but would have to re-rez it on the ground to do so).

EDIT: I might have found a potential reason for this bug, that could possibly happen (although I could not trigger it here) after a cancel action (direct or not) in the color picker.
Could you please try with a recompiled viewer, after changing LLFloaterColorPicker::cancelSelection() (in linden/indra/newview/llfloatercolorpicker.cpp, starting from line 979) to read:
Note: this is just a quick and dirty work-around, and if it works I will come up with a cleaner solution...

No, it was not a rigged attachment. It was an old sculpty prim object from way before rigging was a thing in Second life. And changing the diffuse or normal map textures did not produce a crash. What I was trying to do was to give the prim a low sheen in ALM (to match other mesh components of my suit which have materials) by using a blank texture as the "map" and setting the colour to dark grey. I found that I could set the texture just fine, but the colour kept resetting itself back to white.
Frustratingly I found I couldn't get the crash to repeat doing what I thought I was doing this morning. However I found I could get it to repeat reliably if I pressed the Reset Material button. I have attached the logs to this message.
I applied this patch, and it did indeed fix the crash on pressing the Reset Material button.

Thank you ! It indeed causes a recursion in the original code...
Great ! I applied a better (non-hacky) fix for next release.