Cool VL Viewer forum

hello,

here's the symptom : I crash after 4 or 5 minutes at places with a crowd. ( 30 - 40 avatars usually )
It is reproductible 100 % with my configuration on Windows machine. It never happens when I use a Linux machine. It doesn't seem to happen with Firestorm or the official viewer
Examples of places : HBC, Delust ( crash with 10-15 avatars, but graphics intense avatars ^.^ )

This issue seemed to appear 5 weeks ago ( can't be sure ).
Things I tried :
- using a lower version of the viewer
- upgrading twice to the newer version of the viewer
- downgrading graphics card driver
- using an alt avatar with different attachments

I know my configuration is a little on the lower end. but it was working perfectly well until a few weeks ago.

configuration :
Cool VL Viewer v1.26.22.43, 64 bits, Apr 13 2019 10:09:08
RestrainedLove viewer v2.09.25.20
Release Notes

You are at 462448.7, 303159.9, 901.2 in Myanimo located at
sim10261.agni.lindenlab.com (216.82.49.183:13002)
Second Life Server 19.04.15.526263
Release Notes

CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3192.75 MHz)
Memory: 6087MB
OS version: Microsoft Windows 10 64 bits v10.0 (build 10586.706)
Memory manager: OS native
Graphics card vendor: NVIDIA Corporation
Graphics card: GeForce GTX 750 Ti/PCIe/SSE2
Windows graphics driver version: 25.21.0014.1694
OpenGL version: 4.6.0 NVIDIA 416.94
Detected VRAM: 2048MB
J2C decoder: OpenJPEG: 1.4.0.635d
Audio driver: FMOD Studio v2.00.00
Networking backend: libcurl/7.47.0 OpenSSL/1.0.2l zlib/1.2.8
Embedded browser: CEF3 plugin v3.3626.1895.g7001d56
Packets lost: 1504/64721 (2.3%)

Built with: MSVC v1800

Compile flags used for this build:
/O2 /Oi /MD /MP /DNDEBUG /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /Oy- /GS /fp:fast /TP /W2 /Zc:forScope /Zc:wchar_t- /c /nologo /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DXML_STATIC /DBOOST_ALL_NO_LIB /DLL_LUA=1 /DLL_FMODSTUDIO=1 /DAPR_DECLARE_STATIC /DAPU_DECLARE_STATIC /DCURL_STATICLIB=1 /DLIB_NDOF=1


Thanks for any help you could bring.


Em

It looks like a bug in libopenjpeg (and since LL's viewer and Firestorm are using KDU instead, they are not affected)... But I would need to reproduce the crash in real time myself to see what pointer gets corrupted during the culprit image decoding.

It would also probably happen under Linux (and MacOS-X): it's just that the avatar bearing that texture must be around and in your camera field of view for the crash to happen...

What sim did you see happening into ?

sims where I'm sure to crash in a matter of under 5 minutes are :
- HBC ( Heavy Bondage Club )
- Loseria
- and also DeLust, to a lesser extent

Today, I turned on Advanced / Memory / "Memory Usage Safety checks", and I got veery frequent warning messages, and camera was reset back in position

That would be a different issue, then... Out of (virtual) memory error, that libopenjpeg won't detect, causing a crash... Check how much memory the viewer consumes, and how mush is left. The safety checks try and limit your memory usage when available (non-fragmented) memory gets low, which is why your camera is reset.

Note that for modern 64 bits viewers, systems with less than 8Gb of RAM might prove too small. The Linux version of the viewer is better in this respect, but don't expect miracles either, and make sure not to push the textures VRAM (in the Graphics/GPU preferences) too high.

so . maybe what I did is push the VRAM setting too low ? I pushed it to 864..MB, when I have 2 GB.
hmm.. let me try right now.

And I had removed the Advanced / Memory / "Memory Usage Safety checks", forcing the Viwer to crash ?

that would be the reason ?

No, you should not push it too high: 864MB reserved for textures in your graphics card VRAM will cause around 2GB of CPU RAM to be consumed, just for the textures.

No, the viewer tries to warn you when it sees the memory getting low, and it takes measures to raise the textures "discard level" (meaning using lower resolution textures where possible), also resetting your camera if it notices the memory is about to be exhausted and that you are caming away (which consumes a lot more texture memory and thus RAM).

Also check that you do NOT have "TextureLoadFullRes" debug setting enabled: that one is a memory "exhauster" and will cause crashes in the end...

I had checked "TextureLoadFullRes" settign, it's set to FALSE. I read about it in another topic.

I have raised VRAM from 864 to 1580, and things are rezzing a little faster than before.
At least I am not getting the warnings now, with only 4 people around me and just a slight camming

btw :
- draw distance is set to 64m ( been like this for 6 months now ).
- setting for Max avatars to render is set to 12, or even less


as a recap :
VRAM 864M / 2048 , and ""Memory Usage Safety checks" unset : repetitive crashes in places with 30-40 peoples.( even when it is supposed to render only 12 avatars . is it really obeying the setting ? ). there is a Viewer popup saying hat memory is too lo and will probably crash (a memory allocation failure occured )
VRAM 864M / 2048 , and ""Memory Usage Safety checks" set : frequent warnings about resetting camera view ( to retrieve memory )
VRAM 1580M / 2048 , and ""Memory Usage Safety checks" set : seems OK when with few people around, but still crashing ( with my 'system' browser open ).

it's this message (a memory allocation failure occured ) that I want to try clear away. Remember. it was working fine only a few weeks ago .

I remember now setting to 864 so that I could run 2 viewers at the same time. I was able to run 2 viewers at the same time before.

something that I noticed :
if I leave the browser ( FF ) open at the same time than the viewer,then I crash more frequently.

The free memory computation of the "safety checks" feature was designed for 32 bits releases (back when only 3Gb of virtual address space was available to the viewer), and under Windows, it is rather inaccurate (unlike its Linux counterpart) because of brain-dead system calls under this Mickey Mouse OS...

As for having more crashes when other programs are running, it's only normal: the less memory available to the viewer and the faster it will get exhausted, causing crashes in components that do not check for NULL pointers returned by failed malloc() calls (the third party libraries are such components). While I took great care to check for memory allocation failures in the viewer itself (and to allow for a graceful way of dealing with them instead of crashing in your face), the other libraries are not guarded against such a condition.

I will see if I can add checks to libopenjpeg, but in any case, you will still be faced with memory exhaustion and the need to relog regularly to avoid crashes. In fact, in your case, you could opt for one of the following solutions:

• Use the Linux viewer, which is a much better performer (and using jemalloc for memory allocations) and stabler.
• Add some RAM to your computer (8GB is a minimum nowadays, and 16GB is the "safe" choice).
• Recompile the viewer under Windows as a 32 bits binary: it will consume much less memory than the 64 bits version, and the "safety" checks will work much better to prevent crashes. This will however still require you to relog each time the low memory warnings will appear.

Thanks for the explanations about the memory handling details.
This definitively convinces me of switching to Linux at least for the Viewer. I have countlessly witnessed much better performances with LInux than on Windows on the same computer.
it's just because I had upgraded to a much better computer ( still very low to toda's standards ) thatI had dared go the Windows way.
but it's been a rough ride , having to deactivate all sorts of tasks that bring the computer to almost a halt.

OK, I'll tell you about it soon.

thanks : )

About Windoze: do make sure you have a large enough swap space (as much as your RAM).

The "memory safety checks" feature was mostly implemented to prevent crashes during virtual address space exhaustion (which was easy to achieve for 32 bits binaries, since that space was limited to 3Gb and was getting highly fragmented over time), but it is strange you get it to trigger with the 64 bits viewer, seeing as 64 bits binaries got a virtually unlimited address space and that in case of short physical memory condition, the OS should simply swap RAM blocks with the swap partition to keep going... Of course, also make sure to enable "Allow swapping" in the viewer "Advanced" -> "Memory management" menu...