1.26.1.5 Crash out of nowhere
Author |
Message |
Alexandra.Rucker
Joined: 2011-03-09 13:18:17 Posts: 40
|
I also have a very VERY large number of fonts - over 600 - on my system. Didn't realize that could be an issue. :/
|
2011-09-23 20:48:15 |
|
 |
Amalia Illios
Joined: 2010-04-07 08:23:18 Posts: 215
|

That's kinda insane. Is that a Linux only thing or does it do that on other platforms as well? I mean, I fixed it now by giving the viewer its own font.conf via setting an environment variable in the start script. But if this is happening on all platforms ... talk about oodles of RAM going to waste for people! That makes sense. I don't think I have ever touched that one, but I'll check next time I'm on. Thank you for pointing that out and explaining it. I did a brief test run over at Damsel earlier, and I have to say I needed to cam around a lot more than usual to finally reach the 3 GB threshold this time, without having touched the values at all so far. I'll experiment some more and will report my findings. I presume the reason this is hitting me may actually be a combination of the lacking 1GB in address space that my graphics adapter steals with the fairly extensive screen real estate. If I understand correctly, all LOD calculations and whatnot take the current size of the window/screen into account, so this may well result in a higher memory usage right from the start? Love, Lia
|
2011-09-24 06:54:09 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6043
|

It should affect all platforms since this is not Linux-specific code. Care to share your trick with us ?  Yes, caming on avatars triggers the loading of their attachments textures at low discard level, so the memory usage climbs rapidly when you do. Nothing that can be done to prevent this to happen, alas. Actually, the viewer will never use over 512Mb of *texture* memory in your graphic card, but the rest of the memory is used for other purposes (VBO, FBO and stuff). The problem is that for each texture loaded in your video card memory, there is a copy of it in the PC main memory and the viewer uses a buffer to store these copies that is up to 150% larger than the texture memory used in the video card (meaning that if you set the video texture buffer size to 512Mb, the viewer will use up to 768Mb of RAM on the CPU side). You can significantly lower the memory usage by reducing the texture memory setting in the Hardware Graphic settings (reducing it to 256Mb should bring almost half a Gb of gain in crowded or texture-heavy sims), at the cost of more half-blurry textures in your field of view. This is true for HUD attachments (but this would make only a few megabytes of difference on larger screens), but I'm not convinced it's the case for the rest (since the field of view wideness should not depend on the screen size but only on the virtual camera zoom level and focal length)... You could see by yourself, by reducing the size of the viewer window. In any case, I found a way to convince tcmalloc to release freed memory to the system and posted a new overlay package containing a patched tcmalloc version. See this message for details.
|
2011-09-24 14:57:11 |
|
 |
Amalia Illios
Joined: 2010-04-07 08:23:18 Posts: 215
|

It's not a particularly clever or practical one. I copied fonts.conf to stupid.conf in /etc/fonts, removed all the <dir>...</dir> entries and added the viewer's fonts directory as sole directory containing fonts. Then I added this to the startup script: This works for me, and reduces the startup memory usage (i.e. what is used when it sits waiting for login) by just about 700something MByte (for 609 fonts, or so fc-list claims). Blurry textures! Can't have that! Seriously though, I played with that in my experiments, but it felt like it didn't have a major impact on stability. I obviously couldn't see it due to tcmalloc, but since ... ... I will revisit that once again. I will, at some point. I'm not as "desperate" anymore as I was, since with the fonts avoided and your tweaks in 1.26.1.8, things are no longer in a really critical area. I watch the memory use now, and when I see it reaching dangerous levels, I either let people know I'm about to crash and/or I relog. But I will certainly do a bit more experimentation here and there, if only to satisfy my own curiousity. Love, Lia
|
2011-09-25 04:47:58 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6043
|
Well, now all you have to do is to TP away in a quieter area (a skybox is perfect), wait a minute or two for the textures to get unloaded so that the memory is freed, then TP back to your friends.
|
2011-09-25 08:37:19 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6043
|

 |  |  |  | Amalia Illios wrote: It's not a particularly clever or practical one. I copied fonts.conf to stupid.conf in /etc/fonts, removed all the <dir>...</dir> entries and added the viewer's fonts directory as sole directory containing fonts. Then I added this to the startup script: This works for me, and reduces the startup memory usage (i.e. what is used when it sits waiting for login) by just about 700something MByte (for 609 fonts, or so fc-list claims). |  |  |  |  |
Hmm... I tried but for me it still tells me "35 system fonts loaded", with or without your trick... Perhaps it's because you have got a .fonts/ directory full of fonts in your home directory (~/.fonts/) ?... I don't have one, so only the basic system fonts are loaded by fontconfig. Also, I used a custom font.conf (see below), local to the viewer installation (I put it in the fonts/ sub-directory of the viewer installation directory), removing *all* the <dir> ... </dir> entries (you don't need to add the viewer fonts dir either: LL's patched fontconfig, which is statically linked to the viewer, will automatically add them), and using the following lines in the "snowglobe" wrapper script: Could you please try and tell me if it works for you ?... If it does, I could make this work around part of the next releases. 
fonts/font.conf file:
|
2011-09-26 09:56:31 |
|
 |
Amalia Illios
Joined: 2010-04-07 08:23:18 Posts: 215
|

No, no ~/.fonts, all my stuff is installed in the system font directories. Apart from that, the log probably isn't telling the whole truth. It tells me something about 76 fonts. /proc/<pid>/maps begs to differ.  Not working. See below why.  Depending on where you want to put this, using pwd might of course yield the wrong result, since the cd is way below all the variable declarations. Then again, who am I to tell you that? As I mentioned, it didn't work. Took me a while to figure it out, but you deleted too much stuff, resulting in an invalid XML, which is subsequently ignored. Inserting a <config> above the comment for the Unicode character declarations fixed that. After that, same result as with my first try, with no directories included. Less virtual used, but only little boxes on the HTML start page. Rest working fine. With viewer font directory added, all is peachy! This might be because I've been very bad and messed with the font settings of the viewer anyway to have it use my preferred font (I know, I probably deserve a spanking for that  ), then again maybe not. It's late, I'm cranky, and so that experiment will have to wait. Nonetheless, thank you for having another look into this. Love, Lia
|
2011-09-26 20:30:07 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6043
|
I thought it was rather obvious that the export should be placed after the 'cd "${RUN_PATH}"' line... But I should have specified it. You are right... If only the guy who wrote the original XML had any clue about indenting... Anyway, even once the file is fixed, I see no difference here (still 35 system fonts loaded, plus the viewer fonts). Not seeing that here... Well, in any case it doesn't look like a very portable trick (probably because of distro-patched fontconfig), so I guess I'll not use it... Thanks for your contribution nonetheless.
|
2011-09-26 21:16:48 |
|
 |
Amalia Illios
Joined: 2010-04-07 08:23:18 Posts: 215
|
Now that is bizarre. With no directories specified and the setup proposed by you (or mine, doesn't make a difference -- as it should), I get DejaVu and so on obviously not found, since there's no font paths -- the Arial Narrow is found due to the fact that I put it into skins/default/xui/en-us/fonts.xml with a full path. So understandable that the HTML content only gets the little blocks -- 0 system fonts for me. Certainly seems that way. Well, as I initially said, at least it's now documented and maybe someone else with a similar issue on Ubuntu 10.04 can profit from it. I'm always up for help with what little I can achieve. I've essentially stuck with Cool almost since I joined SL, and it has served me so well over the years, it's the least I can do! Love, Lia
|
2011-09-27 16:29:44 |
|
|
Who is online |
Users browsing this forum: No registered users and 2 guests |
|
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
|
|