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...