Cool VL Viewer forum

Thank you !

Sadly, the information (crash somewhere inside LLSkinningUtil::updateRiggingInfo()) is insufficient for me to find the reason for the crash, and I so far could not reproduce this crash (maybe it is related with some mesh your avatar is wearing, or some mesh around your avatar when you TP).

Since you got a custom build, you should be able to run it under gdb (1).

As long as you did have eu-strip (2) installed on your system before the build, and did not delete the build directory, the debug symbols (3) for your build will be automatically found and loaded when launching the viewer from a terminal with (4):
Then type run in the debugger command line and reproduce the crash: the viewer will freeze and, from the terminal, type bt (back trace) in the debugger command line to get the detailed stack trace.

You can then just copy/paste the info from the terminal into your forum reply.

Type quit and confirm with Y once you are all done, to exit the debugged viewer instance.

---

(1) Or even better, with lldb if you built it with clang. clang/lldb produce way better stack traces than gcc/gdb...
(2) From the elfutils utilities package.
(3) in the linden/viewer-linux-x86_64-release/newview/CoolVLViewer.debug file. You may also move this file along the viewer binary (in CoolVLViewer-x86_64-1.32.2.55/bin/) if you want to be able to debug your build later while you will have deleted the build ditrectory.
(4) Or, for clang builds and lldb:

EDIT: Or even simpler: download the debug symbols for the official 1.32.2.55 build tar ball (sha1sum: 796a958ef9d6324f12721f3d5cb0f8f048eede8e), extract the CoolVLViewer.debug file (beware, it's huge: 1.2GB) and place it inside the bin/ sub-directory of the official viewer build installation directory. Then ensure you got gdb installed on your system and run the viewer from a terminal with the --debug option, like explained above.

OK. I hope I got this right..
(gdb) bt
#0 LLSkinningUtil::updateRiggingInfo (skinp=0x7fffd5caca00, vol_face=...) at /root/cv132255/indra/newview/llskinningutil.cpp:221
#1 0x0000555555ec0ae9 in LLMeshRepoThread::lodReceived (this=<optimized out>, mesh_params=..., lod=0, data=<optimized out>, data_size=<optimized out>) at /root/cv132255/indra/newview/llmeshrepository.cpp:2296
#2 0x0000555555ec0ffd in LLMeshRepoThread::fetchMeshLOD (this=<optimized out>, mesh_params=..., lod=0, can_retry=<optimized out>) at /root/cv132255/indra/newview/llmeshrepository.cpp:2063
#3 0x0000555555ec4ac3 in LLMeshRepoThread::run (this=0x7fffd98bb400) at /root/cv132255/indra/newview/llmeshrepository.cpp:1227
#4 0x0000555556fa23af in LLThread::threadRun (this=<optimized out>) at /root/cv132255/indra/llcommon/llthread.cpp:191
#5 0x00005555572ec1f7 in thread_proxy (param=<optimized out>) at libs/thread/src/pthread/thread.cpp:177
#6 0x00007fffe769caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#7 0x00007fffe7729c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)

Perfect, thank you !

Apparently, the viewer is trying to access a non-existent volume face (which would also explain why the mutex code crashed last week)...

And I think I found the bug (which also exists in LL's viewer): the wrong method is used to get the number of volume faces in the mesh object (the object profile faces number is used instead, causing a crash when the mesh got less faces than the profile).

I compiled a test viewer for you to try it. If everything works as expected you will not crash but will read in the log:
(with M < N).

I will send you a PM to give you the links to the test build (for your eyes only), as well as to the corresponding debug symbols tar ball, in case you would still get a crash...


EDIT: Jeeper PMed me to say he was not seeing any crash any more. I will publish a v1.32.2.56 emergency release with the bugfix, since this bug could actually occur in SL as well, and only depending on the meshes you encounter on rezzing; for example, meshes with 1 or 2 faces for the lowest LOD0 could definitely crash, or at least causes access to uninitialized std::vector elements (by pure luck you won't crash just because vectors are usually expanded to the next multiple of 8 or 16 elements).