Cool VL Viewer forum
http://sldev.free.fr/forum/

Crashes with Memory Allication Failure
http://sldev.free.fr/forum/viewtopic.php?f=6&t=2306
Page 1 of 4

Author:  DonFranko [ 2022-10-03 12:49:20 ]
Post subject:  Crashes with Memory Allication Failure

Hi Henri,

since I use Zane's auto-derender script things got a lot better, but still I have big problems zooming when there are some people in a venue, sometimes I even crash when only a couple people are visibile for me. All of as sudden I get a Memory Allocatin Failure and then terrible crash that also effects the graphics settings of my pc (e.g. like the night light gets turned off)

Attached you find the infos, hoping you can find the issue.

Many thanks in advance!

Attachments:
logs.7z [26.51 KiB]
Downloaded 47 times

Author:  Henri Beauchamp [ 2022-10-03 14:19:34 ]
Post subject:  Re: Crashes with Memory Allication Failure

Not an issue with the viewer itself, I'm afraid... If the OS reports a NULL pointer on a memory allocation request, all the viewer can do is report the problem to you and try and take conservatory measures (but the latter are limited, and some allocation failures cannot be trapped, causing crashes in the end).

What you must find out is why the Hell your OS fails to allocate memory when there is still memory available to it !

Also, you should not be forced to derender avatars at all: I can attend venues with 80+ avatars and never run short of memory.

Usual suspect are viruses/malware or... the anti-virus itself !

Try and use the task manager to detect the memory "eater".

Author:  DonFranko [ 2022-10-03 17:00:07 ]
Post subject:  Re: Crashes with Memory Allication Failure

So, it's good to know that it's not the viewer , although that was quite clear as nobody else is complaining about Memory Allocation Crashes afaik. But as the crashes only happening with the viewer I thought of checking back with you.

I attached a few screenshots of the CPU-Z app. Since some time I have a feeling that the problems occur because of that what you see at the screenshots. I have two Ram sticks and of em seems to be inconsistent with regards to the power Voltage. Could that be a reason to cause these kind of troubles when a lot more Ram than usually is used?

and.. Does the log say OS or also about the GPU?

Attachments:
SPD Slot 2.PNG
SPD Slot 2.PNG [ 21.66 KiB | Viewed 1251 times ]
SPD Slot 1.PNG
SPD Slot 1.PNG [ 21.51 KiB | Viewed 1251 times ]
Memory.PNG
Memory.PNG [ 18.46 KiB | Viewed 1251 times ]

Author:  Henri Beauchamp [ 2022-10-03 18:19:00 ]
Post subject:  Re: Crashes with Memory Allication Failure

I see nothing wrong with the DDR settings, and should you have memory corruption issues, it won't translate in OS memory allocation failures but rather in random crashes...

Again, try and use the Windows task manager to see what amount of memory the processes are consuming, and spot the culprit.

Author:  Henri Beauchamp [ 2022-10-03 18:46:09 ]
Post subject:  Re: Crashes with Memory Allication Failure

Looking at the start of the log, I see weird issues that would hint for a corrupted viewer installation:
Code:
2022-10-03 08:33:35Z WARNING: LLViewerMediaImpl::newSourceFromMediaType: ONCE: Could not find launcher at C:\Program Files\CoolVLViewer-1.30.0\SLPlugin.exe
2022-10-03 08:33:35Z WARNING: LLViewerMediaImpl::newSourceFromMediaType: Plugin intialization failed for mime type: text/html
Missing SLPlugin.exe ?

Code:
2022-10-03 08:34:55Z WARNING: LLPanel::getString: Failed to find string cardinals in panel radar
2022-10-03 08:34:55Z WARNING: HBFloaterRadar::postBuild: Invalid cardinals string in floater XUI definition.
Corrupted (or old) mini-map panel definition file ?

CONCLUSION: uninstall and reinstall the viewer...

There are also strange settings, in your configuration:
Code:
2022-10-03 08:33:34Z INFO: LLViewerTextureList::getMaxVideoRamSetting: Usable texture RAM: 12288 MB - System RAM: 16383 MB.
2022-10-03 08:33:34Z INFO: LLViewerTextureList::updateMaxResidentTexMem: Total usable VRAM: 4000 MB - Usable frame buffers VRAM: 512 MB - Usable texture VRAM: 3488 MB - Maximum total texture memory set to: 6976 MB - Maximum total GL bound texture memory set to: 2560 MB
You should really avoid using that many VRAM for textures (7GB or so) on a system with only 16GB of RAM, given the viewer needs about 1.5 times the RAM you set for the VRAM... Set it down to 2560MB or 3072MB max of "Texture memory" (in Preferences -> Graphics -> GPU/GL features).

Code:
2022-10-03 08:33:26Z INFO: LLAppCoreHttp::refreshSettings: Application settings overriding default texture fetch concurrency. New value: 2
2022-10-03 08:33:26Z INFO: LLAppCoreHttp::refreshSettings: Application settings overriding default mesh fetch concurrency. New value: 2
2022-10-03 08:33:26Z INFO: LLAppCoreHttp::refreshSettings: Application settings overriding default mesh2 fetch concurrency. New value: 2
This is uselessly slowing down your rezzing experience: raise to at least 8 for each (in Preferences -> Network & Web, Max* requests spinners).


Also, a factor (not visible in viewer logs) that could cause memory allocation failures under Windows would be the absence of any swap file (should you have manually set it to none)... For 16GB of RAM, Microsoft recommends a 4GB page file (=swap file).

Author:  DonFranko [ 2022-10-03 22:49:14 ]
Post subject:  Re: Crashes with Memory Allication Failure

Henri Beauchamp wrote:
Looking at the start of the log, I see weird issues that would hint for a corrupted viewer installation:
Code:
2022-10-03 08:33:35Z WARNING: LLViewerMediaImpl::newSourceFromMediaType: ONCE: Could not find launcher at C:\Program Files\CoolVLViewer-1.30.0\SLPlugin.exe
2022-10-03 08:33:35Z WARNING: LLViewerMediaImpl::newSourceFromMediaType: Plugin intialization failed for mime type: text/html
Missing SLPlugin.exe ?
I just de-activated it yesterday to try something out and forgot to re-enable it. That seems to have nothing to do with the crashes actually.

Quote:
Code:
2022-10-03 08:34:55Z WARNING: LLPanel::getString: Failed to find string cardinals in panel radar
2022-10-03 08:34:55Z WARNING: HBFloaterRadar::postBuild: Invalid cardinals string in floater XUI definition.
Corrupted (or old) mini-map panel definition file ?

CONCLUSION: uninstall and reinstall the viewer...
I will do that. Can I keep my all the data of my profile as the files are only in the program directory?

Quote:
There are also strange settings, in your configuration:
Code:
2022-10-03 08:33:34Z INFO: LLViewerTextureList::getMaxVideoRamSetting: Usable texture RAM: 12288 MB - System RAM: 16383 MB.
2022-10-03 08:33:34Z INFO: LLViewerTextureList::updateMaxResidentTexMem: Total usable VRAM: 4000 MB - Usable frame buffers VRAM: 512 MB - Usable texture VRAM: 3488 MB - Maximum total texture memory set to: 6976 MB - Maximum total GL bound texture memory set to: 2560 MB
You should really avoid using that many VRAM for textures (7GB or so) on a system with only 16GB of RAM, given the viewer needs about 1.5 times the RAM you set for the VRAM... Set it down to 2560MB or 3072MB max of "Texture memory" (in Preferences -> Graphics -> GPU/GL features).
I read that 2/3 of the total VRAM of the Graphics card would be the optimal size. That is why I put it to 4 of the 6GB. But I hear your advice and lowered it to 2544 (as don't know who to fine change the value). Is that the only setting triggering all the other figueres?

Quote:
Code:
2022-10-03 08:33:26Z INFO: LLAppCoreHttp::refreshSettings: Application settings overriding default texture fetch concurrency. New value: 2
2022-10-03 08:33:26Z INFO: LLAppCoreHttp::refreshSettings: Application settings overriding default mesh fetch concurrency. New value: 2
2022-10-03 08:33:26Z INFO: LLAppCoreHttp::refreshSettings: Application settings overriding default mesh2 fetch concurrency. New value: 2
This is uselessly slowing down your rezzing experience: raise to at least 8 for each (in Preferences -> Network & Web, Max* requests spinners).
And that has no impact on the used kernels of my cpu, right? As I need 7 of the eight kernels for my DAW with the great Piano Vst that I'm using. I set all three of em to 8 and see what happens

Quote:
Also, a factor (not visible in viewer logs) that could cause memory allocation failures under Windows would be the absence of any swap file (should you have manually set it to none)... For 16GB of RAM, Microsoft recommends a 4GB page file (=swap file).
I double-checked that one. When I go to the relevant settings, Windows recommends to set the size to 2943, what I did, but I try with 4GB as I trust you more than windows :))

Author:  DonFranko [ 2022-10-03 23:09:47 ]
Post subject:  Re: Crashes with Memory Allication Failure

Henri Beauchamp wrote:
I see nothing wrong with the DDR settings, and should you have memory corruption issues, it won't translate in OS memory allocation failures but rather in random crashes...
So the different voltages of the two channels of that one stick are not a problem?

Quote:
Again, try and use the Windows task manager to see what amount of memory the processes are consuming, and spot the culprit.
I'll do that. Thanks for the hint

Author:  Henri Beauchamp [ 2022-10-04 08:20:40 ]
Post subject:  Re: Crashes with Memory Allication Failure

DonFranko wrote:
Can I keep my all the data of my profile as the files are only in the program directory?
Yes, the Cool VL Viewer (un)installer does not touch them at all.

DonFranko wrote:
I read that 2/3 of the total VRAM of the Graphics card would be the optimal size.
No, not when your graphics card got almost as much VRAM than your have RAM in your system ! Each texture in VRAM got two different copies (un-decoded and decoded) in RAM, and it means you need roughly 1.5 times as much RAM as the texture VRAM setting. Beside, over 3GB of VRAM for textures is an overkill anyway, even at 512m draw distance in main land.

DonFranko wrote:
And that has no impact on the used kernels of my cpu, right? As I need 7 of the eight kernels for my DAW with the great Piano Vst that I'm using.
These settings do not affect how much CPU cores (1) are used by the viewer, however the condition you impose is extremely strict, and never truly met since the viewer is very much adamant on using as much threads as it can, threads that will be spread over various cores by your OS, unless you limit the cores for the viewer at the OS level via the "core affinity" feature (2)...
If you want the viewer to be as mono-threaded as possible, you need to set the graphics driver (system-wide) setting for not multi-threading (meaning 30%-50% less fps); this is true for any viewer.
For the Cool VL Viewer, you will also want to set the number of image decode threads (Preferences -> Cool features -> Misc) and GL worker threads (Preferences -> Graphics -> GPU/GL features) to (respectively) 1 and 0, which will degrade your rezzing experience...
If I were you, I'd upgrade my PC with a better CPU (with 12 or 16 (real, not virtual/SMT) cores)...

(1) The "kernel" is the OS "core" (main, central) software component. CPUs have hardware cores (true/genuine cores which may be seen as two virtual CPU cores when the CPU cores have SMT), not kernels.
(2) From the Windows task manager (advanced/tabbed view), in the "Details" tab, right-click on the CoolVLViewer.exe process and choose "Set affinity" (or whatever is it called in English or your language), and uncheck all but one core (two (even and uneven consecutive ones) if you got SMT cores: e.g. cores 0 & 1). Proceed the same way with your sound software, affecting all other cores to it.

DonFranko wrote:
So the different voltages of the two channels of that one stick are not a problem?
You are looking at a table of available JEDEC/XMP profiles (supply voltage vs RAM speed), not at the actual voltage in use (which is likely only available from your BIOS screen, not from CPU-Z & Co).

Author:  DonFranko [ 2022-10-04 09:06:45 ]
Post subject:  Re: Crashes with Memory Allication Failure

Thank you very much, Henri!

I will have a look into all of that.

Just right now after I've done the other changes I went to the lelutka shop, stayed there for a while and walked around looking.. then I flew back home where no traffic is.. then after 30 seconds crahsed and closed itself again. Would you mind having anouther look at the current log to maybe detect a reason for it?

Attachments:
File comment: Now it should be included
logs.7z [39.49 KiB]
Downloaded 47 times

Author:  Henri Beauchamp [ 2022-10-04 09:14:14 ]
Post subject:  Re: Crashes with Memory Allication Failure

DonFranko wrote:
Just right now after I've done the other changes I went to the lelutka shop, stayed there for a while and walked around looking.. then I flew back home where no traffic is.. then after 30 seconds crahsed and closed itself again. Would you mind having anouther look at the current log to maybe detect a reason for it?
Please, also post the CoolVLViewer.dmp crash dump file, since this is a viewer crash (unrelated with memory issues) that needs addressing.

Page 1 of 4 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/