Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2022-01-21 19:54:48



Reply to topic  [ 9 posts ] 
InWorldz memory allocation errors 
Author Message

Joined: 2015-01-18 06:58:21
Posts: 6
Reply with quote
I searched and could not find any mention of anyone else having this issue, so I thought I would try and report it. I'm rather hoping it's something I've done wrong and can correct. I use Cool VL to connect to the InWorldz grid. Of late I have been getting memory allocation errors with crashes soon afterwards. I can rapidly replicate this by going to nearly any busy club for dancing etc. I've zipped up and attached the log files that were specified and I feel certain I am using the latest linux version. I tested with the InWorldz (Firestorm derived) viewer, which I loathe, and the error/crash situation did not occur.
I use LXLE Linux 14.04.....which is a Lubuntu derived distribution.


Attachments:
Log files.bz2 [24.57 KiB]
Downloaded 134 times
2015-01-18 07:11:35
Profile

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
The relevant log lines are these:
Code:
2015-01-18T05:33:04Z WARNING: LLFacePool::getRiggedGeometry: Skipped bad face. mNumVertices = 669545520 - mNumIndices = 762521312
2015-01-18T05:33:04Z WARNING: LLFacePool::getRiggedGeometry: Skipped bad face. mNumVertices = -1120737246 - mNumIndices = 0
2015-01-18T05:33:04Z WARNING: LLFacePool::getRiggedGeometry: Skipped bad face. mNumVertices = -1097334784 - mNumIndices = 1050148864
2015-01-18T05:33:04Z WARNING: LLFacePool::getRiggedGeometry: Skipped bad face. mNumVertices = -1 - mNumIndices = 669863296
2015-01-18T05:33:04Z WARNING: LLFacePool::getRiggedGeometry: Skipped bad face. mNumVertices = 1050504654 - mNumIndices = 998995616
2015-01-18T05:33:04Z WARNING: LLMemory::allocationFailed: Memory allocation failure for size: 1209292800
2015-01-18T05:33:04Z WARNING: LLFace::getGeometryVolume: ONCE: vf got NULL pointer(s) !
2015-01-18T05:33:04Z WARNING: LLTextureFetchWorker::callbackDecoded: DECODE FAILED: 5c025df1-b7ab-4000-af45-b082763b3b3b Discard: 3
2015-01-18T05:33:04Z WARNING: LLTextureFetchWorker::callbackDecoded: DECODE FAILED: 4d25da16-d5f9-43ef-b45d-f4efc4746f5d Discard: 3
2015-01-18T05:33:04Z WARNING: LLAlertDialog::LLAlertDialog: Alert: WARNING: a memory allocation failure occurred because the available virtual memory address space is too low or too fragmented !
The viewer might crash soon...

Reducing the draw distance to 64m and resetting your camera view to free a maximum of memory.

NOTE: you might see black textures appear because of decoding failures. You may force-reload them (right click on object and CTRL SHIFT U, or right click on avatar then 'More' and 'Refresh') after the memory gets freed.
2015-01-18T05:33:04Z WARNING: LLFacePool::getRiggedGeometry: Skipped bad face. mNumVertices = 636913080 - mNumIndices = 343071856

Notice the insane number of vertices associated with that rigged mesh... Not a surprise that it quickly exhausts the available memory.

This is an invalid rigged mesh, probably a crasher object, and it's not a viewer bug (even if there may be a way to detect and take action against such crasher objects; I'll have a look at an auto-derender possibility). Now, it would help identifying which mesh is causing that issue (InWorldz admins may help you doing it).

One question however (since there are two paths in the code where the out of memory condition happens): do you have the mesh deformer feature enabled or not (if enabled, it would explain why other viewers are not affected since they don't have it) ?

EDIT: I found a way to auto-derender such bogus objects and to pin-point them in the log (by their UUID and the name of the avatar wearing them). I will PM you the link to a test viewer including that code (compiling it right as I'm writing these lines).


2015-01-18 08:53:05
Profile WWW

Joined: 2015-01-18 06:58:21
Posts: 6
Reply with quote
I will try what you sent me and want to thank you from the bottom of my heart. One question, is it ok if I share this with the InWorldz developers? Not the viewer of course but this thread and what you discovered, I think knowing this is happening could potentially be helpful to them.....


2015-01-18 14:59:39
Profile

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
SaraNyn wrote:
One question, is it ok if I share this with the InWorldz developers? Not the viewer of course but this thread and what you discovered, I think knowing this is happening could potentially be helpful to them.....
This forum is for everyone to read and share as they wish.

You didn't reply to my question however: do you have the mesh deformer feature enabled or not ?


2015-01-18 15:19:09
Profile WWW

Joined: 2015-01-18 06:58:21
Posts: 6
Reply with quote
I do not....... i haven't seen anything I wanted yet that took advantage of it........


2015-01-18 16:08:53
Profile

Joined: 2015-01-18 06:58:21
Posts: 6
Reply with quote
I just tested the experimental build for about two to three hours and memory usage never rose above about 25% ......this was remaining entirely on my home sim and I will be doing further testing....but this is already a large improvement.......


2015-01-18 16:51:03
Profile

Joined: 2015-01-20 02:30:16
Posts: 1
Reply with quote
Hi Henri! I was wondering if you could share a diff of the changes you made? I'm very curious to see what you've done (we've been chasing memory allocation errors lately too).

Thanks,

McCabe Maxsted (InWorldz developer)


2015-01-20 02:37:25
Profile

Joined: 2009-03-17 18:42:51
Posts: 4809
Reply with quote
McCabe wrote:
Hi Henri! I was wondering if you could share a diff of the changes you made? I'm very curious to see what you've done (we've been chasing memory allocation errors lately too).
The change doesn't involve allocation errors at all: it simply causes invalid rigged meshes (that were already detected but that the viewer kept trying to render nonetheless) to be removed entirely from the viewer objects list (i.e. to be "derendered"); this way, the viewer doesn't try and allocate bogus amounts of memory for an object that is obviously invalid and won't even render properly (even in a 64 bits viewer with gigazillions of available RAM).

That change will be part of this week's releases (and as such, part of the diff and sources published together with the binaries). I'm however still waiting for SaraNyn's confirmation that their problem is solved by this new feature.

As a server-side developer, you could ensure that when a mesh is uploaded, its characteristics (maximum number of vertices per face, total number of faces, etc) are within reasonable limits (the viewers can't cope with more than 65536 vertices per face, for example, but even that number is pretty insanely high, especially if the object contains thousands of such faces...).


2015-01-20 09:28:59
Profile WWW

Joined: 2015-01-18 06:58:21
Posts: 6
Reply with quote
I have not seen the memory allocation error in the experimental version of the viewer. I have seen some very high memory usage in crowded/club type situations but have not suffered a memory related crash while using this version.


2015-01-20 12:49:16
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.