Cool VL Viewer forum

...not kidding, either...

I logged in to:
http://slurl.com/secondlife/Mahe%20Seychelles/133/87/22 - "JAPAN DREAMS SCULPTIES"

and started turning around in a circle to get things to load. Followed partway through the spin by freezing, then white-screen (Windows tossed up the "wait or close?" box) crash. "Japan Dreams" is a shop I'm familiar with, it has a *ton* of sculpts out on display. There might be mesh in there as well, I don't know - most of it didn't load before I crashed.

Prior to going to this sim, the other places I'd teleported to were just fine.

I had this with 1.7 as well, and was going to post those logs when I saw you'd updated - sooner than I expected.

Full logs are attached. Ones not included were 0-byte files.

It says it all:
You simply ran out of memory...

Went over there and turned around at the TP point till everything was rezzed with a 256m draw distance: 1.9Gb used by the viewer.

Then walked around for 5 minutes and it reached 2.4Gb. No crash. For sure, it's a very (insanely, even) texture-heavy sim... But try the same with other viewers, and you'll get the same results.

So, I get to look forward to that every time my cache fills up? Yayyyyyy */sarcasm* I'll drop back to an earlier version again then.

Earlier v1.26.1 versions will consume even more memory... Try v1.26.0.20 if you don't need meshes.

Went back to the (20) version already - and that sim isn't giving me a lick of trouble now.

Something with the mesh-specific stuff, then? I've got 12GB RAM and a 1GB video card, someone with lesser power under the hood will find this even more of a showstopper than I do.

This is because of the use of tcmalloc which never releases to the system the memory it claimed for the process and that was freed by the latter (the freed memory is kept in tcmalloc pool and reused for the process when it needs memory). This can cause the system to run out of memory and kill the viewer. Alas, tcmalloc is needed for aligning allocated variables and structures used with SSE2 operations used by the mesh code... This affects all mesh viewers.

This said, I only got 4Gb of memory and can run v1.21.1.8 without any problem in the sim you visited... Of course, I'm under Linux, but still...

Note however, that there is a good reason for v1.21.1.8 to still be flagged "experimental", and this memory issue is actually the only reason (since the rest, including mesh rendering, works like a charm).

Well, I'm under Vista these days, which is known to be a bit squirrely and system hoggy itself. But it's better than the last box, which was having trouble even running Nicholaz's viewer back in the day.

Tcmalloc, that's the meshy thing I was trying to think of. YOUR experimentals usually work better than most, so I tend to forget that it's actually still experimental.

If I remember things correctly then a 32-bit process can usually only use 2gb RAM in Windows. But there is a flag (LargeAddressAware) which can be set in the EXE that when run on a 64-bit Windows, the process can use 4gb RAM. Maybe that will push the out-of-memory error far enough away that it won't crash. Or at least not that quickly.

There is of course also the /3gb option that you can set in your BOOT.INI. This can expand the user-space to 3gb on a 32-bit Windows. Here too the EXE needs to have the LargeAddressAware flag to be set in order to use this.

I don't know if this flag may be already set by default. Just thought I'd mention it.

Here is a link that describes how to set LargeAddressAware in Visual Studio:
http://msdn.microsoft.com/en-us/library ... 80%29.aspx

It's amazing how shitty this Mickey-mouse operating system they call "Windows" can be... Well, I recompiled and re-released the viewers today with that flag enabled. See this message for details.

From what I gathered from Micro$hit knowledge base, this option is not needed in Windows XP and later (Vista, Seven) and can actually break your video driver when used. It should be only needed in Windows Server 2003 32 bits and earlier. Since I can't test it myself (I run Windows under Linux in a VirtualBox virtual machine and can't allocate more than 2Gb to such a virtual session on a 4Gb host), let me know if it works without that /3GB flag for you. If not, I'll add a word about it in the Windows installation howto.

Thanks a lot for the info: as you could already gather I am not a Windows person and was not aware of such silly (read: utterly stupid and "moronesque") limitations...

What about installing Linux as a dual-boot OS ?... Warning: using Linux can be addicting !

I found out how to convince tcmalloc to release the freed memory to the system and released a new overlay package today. See this message for details.

Well, I'm a conservative and suspicious guy when it comes to coding, so I always give it some time before pretending a release is "stable"... Something others (and in particular Linden Lab) would be well inspired to do as well: it amazes me that they dare calling v3.0.0/3.0.3 release viewers when they crash on you every few minutes (when not on launch) ! These are probably the less reliable viewer versions LL ever released and are not even worth the label of alpha viewers.