I can't build like this - I'm a content creator.

I'm running on a dev server so a decent spec PC (dual core, 2GB RAM, NVidia 8500GT, high speed internet. SL was flying prior to update. Have disabled stacks of options, but it still happens. Every minute or two it freezes, for between 5 and 30 seconds. The SIM I build on is Chelsea, and very quiet - often only a few hundred prims there. I have also not enabled voice.

I have heard from 3 others that they have similar issues although not as much as mine which is unusual as my PC is better spec than theirs, which makes me wonder if the code is now doing something extra - like running through inventory or something and perhaps I have a bigger inventory - or something like that?

Please post a solution for this. Its extremely frustrating.

The machine Im using is a Pc dual core AMD 5400+ , 2GB RAM , Nvidia 7600GT , running XP Pro ( fully updated)

REALLY irritating,

I am on a Dual core 2ghz with a Geforce GO 2 gb ram.

Noticing that there are a lot of people with dual core cpus here. Maybe it's a dual core specific problem ?

Helwett-Packard Pavillion
CPU: Pentium4 2.4 GH
RAM: 512
OS; Windows XP media center edition. Service pack 1
ATI RADEON 9200 graphics card.

I've had a freeze (10-20 seconds) today in the debugger. From what I saw on the stack, the viewer was deleting motion elements from a list. I could not look at the details but it was motion related.

What I was doing at that time (dunno if that makes a repro) was that I was in edit-appearance mode for a long time (20-30 minutes), uploading textures for a skin, trying them, editing in photoshop, uploading again, trying etc. etc.. The freeze happened when I got out of edit appearence.

Having similar oproblems of total system freeze no mouse no nothing no access to windows by cont alt del during freeze. these freezes are lasting up to 4 minutes at a time. Most prevalent if I go in close look on something, but sometimes happen in normal view. No obvious bandwidth or packet loss problems associated with it. Currently running today with camera constraints in place and it has happened 3 times so far in the last hour.

2007-08-16T14:13:10Z INFO: LLCircuitData::checkPacketInID: packet_out_of_order - got packet 45005 expecting 44958 from 72.5.13.18:13004
2007-08-16T14:13:16Z WARNING: LLAudioChannelFMOD::cleanup error: An invalid parameter was passed to this function
2007-08-16T14:13:21Z INFO: LLCircuitData::checkPacketInID: packet_out_of_order - got packet 45049 expecting 45009 from 72.5.13.18:13004
2007-08-16T14:13:26Z WARNING: LLAudioChannelFMOD::cleanup error: An invalid parameter was passed to this function
2007-08-16T14:18:11Z INFO: idle: Transmitting sessions stats
2007-08-16T14:18:11Z INFO: LLViewerStats::addToMessage: STAT: Version: 1.1802e+010
2007-08-16T14:18:11Z INFO: LLViewerStats::addToMessage: STAT: Vertex Buffers Enabled: 0

Same problems as described, including intermittent loss of LAN momentarily when this freeze occurs. I have found the same thing occurs on my laptop with this version. My other desktop that still has 1.18.0(6) on it is not affected in this manner.

What appears to happen is that something/somewhere goes into 100% CPU utilisation and basically prevents other software from running during the freeze. As such the SL viewer will miss any packets sent during the freeze and it worses cases network driver itself may be affected.

However, it isn't clear what is eating the CPU cycles, which makes me suspect that the process which grabs CPU is not in the viewer itself but in a driver (video? network?) - perhaps some graphics routine not cleaning up properly?

Some general observations:

i) So far I've not experienced freezing in 1.18.0.6 but I'll keep monitoring

ii) When entering a new location in 1.18.2, the FPS would often drop to 1-2FPS whilst the prims and textures where loading - forcing me to stand still until everything had rezzed; in 1.18.0.6 I get no such FPS reduction when entering a new area so I can move around whilst things are loading.

I suppose someone needs to go through all the changes between 1.18.0 and 1.18.2 particularly within the rendering code and perhaps the networking code to track this down?

• while using affinity (on dual core)
• joseph bulloch's pc, on which freezes happen, is a P4 with HT enabled (2 logical cpu's)
• while i came back from being away and did nothing
• while disabling camera constraints is off
• while voice was disabled in the parcel (seen by warkirby)
• while voice is disabled in preferences

This problem is somewhat different from freezing in previous versions and the change in magnitude between frequency and impact of any freezing seen in 1.18.0 and 1.18.2 is huge!

Yes, in 1.18.0, I occasionally get things going sluggish (<5fps) for a second or so, this is irritating but in general doesn't prevent me working with the viewer.

In 1.18.2, things going sluggish (<5fps) is far more common which makes using the viewer almost impossible for anything which requires any degree of accuracy. Moreover whereas sometimes the viewer runs without problems,on others (about 1 in 3), it will suddenly freeze the entire computer - not just the SL viewer - even when the viewer is locked to a single CPU core. When this happens it will last about a minute during which almost nothing is possible on the computer. Also when this happens it will very often reoccur within 5-10 minutes.

In effect, if you are experiencing this problem (and not every one is), the 1.18.2 is useles for anything apart from quickly teleporting to a location and standing or sitting still (which is fine if you just wish to use voice and nothing else )

One thing I have noticed is a sort of blink of the SL viewer just before the freeze happens - has anyone else seen this?

The problem seems to be related to a specific OpenGL extension (GL_ARB_occlusion_query). There is a debug feature in the SL viewer for Linux that allows blacklisting particular OpenGL extensions so that they won't be used during runtime. When I disabled GL_ARB_occlusion_query using this feature, the freezes did not occur. This worked for both ATI and Nvidia. I noticed no change in frame rates, so this seems to be a viable solution.

Unfortunately the extension blacklist feature is not available in the viewer for Windows. Its code gets excluded during precompile if the target platform is not Linux. The source can be viewed here:

http://svn.secondlife.com/svn/linden/release/indra/llwindow/llgl.cpp

(Search for "LL_GL_BLACKLIST".)

After disabling the option, a viewer restart is required for the setting to take effect.

My suspicion is that that the client isn't removing llSpatialPartition objects (and derivative objects) from the rendering pipeline properly or is hanging onto them for longer with the result that the pipeline rendering gets bogged down.

CPU: Intel Core 2 Series Processor (2394 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: ATI FireGL V3400 Pentium 4 (SSE2)
OpenGL Version: 2.0.5886
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Packets Lost: 147/81610 (0.2%)
Viewer Digest: 22d4462a-1f77-e110-1bf7-accb58dc77af

this seems to lock my entire system, not just the viewer, was wondering if this is a reoccurrance of the memory leak bug, or if it was just flushing to disk what SL is keeping in the cache, as the disk usage and processor usage spikes momentarily for the first few seconds, and then 30 seoncds later, the computer is usable again.

I am joining the lamentation over these recurring freezes, which force me to re-boot many, many times a day (constantly fearing a file system corruption, something that SL provoked this summer on my late Windows system).

I have a strong suspicion that the freeze is network related, since the bandwidth gadget tends to be yellow or red just before the freeze.

Also, it seems limited to some regions. I can run for hours without problems, then suddenly I freeze shortly after teleporting. Could sculpted prims be involved?

I'll try with the suggested "LL_GL_BLACKLIST=l", and will return here if that makes things better.

Intel core2 6400 dual CPU 2.13GHz, 204MB RAM, NVIDIA GeForce 7950 512MB RAM, all updated drivers.

One thing I noticed, when this started happening I opened the Task Manager during freezes and every time there were 2 Secondlife aplications showing both marked not responding. Checking processes, one was Secondlife.exe and the other was Explore.exe, and as soon as the freeze ends the 2nd, Explore.exe dissapears again.

Often after a freeze the Secondlife window retains the (not responding), although everything works fine.

Don't know if any of these obsevations are useful as I know little of the workings of computers.

PowerMac G5 2.5 GHz, 3.5 GB RAM, Radeon X800 XT

Practically every time I turn around, or pan my camera around I will freeze for varying amounts of time. Usually it's around 10 seconds. Sometimes it can be over a minute, leading to a viewer connection time out. Sometimes it's indefinitely. Sometimes indefinitely with a crash reporter dialog.

Talking to my friends on voice, very rarely do a few minutes pass without someone crying out "Argh I'm frozen again!". Same reasons. Turning can be quite lethal. I don't think I know of anyone who uses voice who doesn't freeze up on a regular basis, half the time to the point of crashing.

Disabling voice doesn't change anything. It seems to be a problem concerning how the world objects are buffered and loaded when turning around or panning the camera around/out? It just chokes everything. On the mac you get the beach ball of death (the little whirly loading mouse cursor), and can hear CPU fans kicking in as it starts choking on whatever SL is doing.

A lot of the time I get a stuck key effect too, whereby whatever key I was pressing at the time of the freeze (and let go of after I froze up) will remain stuck even though I'm not touching it. Usually the left mouse button, or a directional key. Pressing the key/button again corrects that. But many times I've ended up barging into people because one of my directional keys was stuck.

This issue has really only been present for me since the later builds of the voice viewer, and the current one. Reverting back to the old, non-voice viewer stops the issue. This is also present in the first RC viewer posted two days ago.

Initially (with new puter)I was dealing with complete viewer crash every ten minutes or so that required a hard boot. I disabled the Open GL Vertex buffers in preferences and that annoying problem went away.

Now I am left with the sticking situation. I can pan camera and everything appears fine, but Ima will not move her tail! I have learned to not touch another key until the freeze has subsided as I have often mowed people down or sent myself into the abyss of the ocean as SL loads every missed command prompted by me during the freeze. I have disabled object-object in client and disabled voice as well. Disable voice helped only slightly. All drivers are current. I have the nVidia 6600 Geforce. The computer was purchased based on the recommended specs as displayed in sys requirements for SL.

I am not computer savvy so I am at a loss with this one. I do hope it gets resolved soon as the freezing makes building and interacting.

I have been told by others that disabling voice seems to reduce the frequency and duration of these freezes, but doesn't stop them.

Specs:
Windows XP
Nvidia GeForce GO 7900GS
2 GB RAM
Intel Core Duo

AMD FX-57
Nvidia 7800gtx 256mb
3GB RAM

So far this is what I have done to cure this problem and it is current 98.9% under control. No more sticking, or only standing in place able to turn.........

Yesterday I took my Toshiba Qosmio laptop outside on the porch with me to enjoy the cool weather.....All the freezing, sticking ceased.....Hmmmm
Tested (inside house) router-Sticking, freezing, standing in place only able to pan camera.
Bought Targus chill pad for laptop.....All prblems resolved!

I think a good deal of this problem is with the nVidia cards getting so hot so fast. Anyway, I'm sure this is not the cause of all the problems but it did resolve mine and thought I would post as something to try. If you are like me, it is annoying enough that you will try anything at this point..............

G'day
Ima Rang

kk. Hope this helps...

Desktop #1
HP Desktop w/ Core2 Duo processor
2G RAM
Windows XP Service Pack 2 & all current patches
Nvidia 7600GS w/ 512M video RAM (PNY card; PCIe)
Network connection via Ethernet

Desktop #2
HP Desktop w/ Core2 Duo processor
2G RAM
Windows XP Service Pack 2 & all current patches
Nvidia 7600GS w/ 256M video RAM (PNY card; PCIe)
Network connection via 802.11g & Linksys router

Laptop #1
HP dv6000 laptop w/ Core2 Duo processor
2G RAM
Windows Vista
Nvidia GeForce Go 7400 w/ 128M video RAM
Network connection via 802.11g & Linksys router

Both my wife and I see it with moderate-to-high frequency when camera-ing around and when turning in place.

One reason (there may be others) for such stalls is cache cleanup work. It will mainly happen if you travel much (visiting sims with new textures which you don't have in the cache). OTOH after a cache clean, it will not occur for some time (until the cache fills up).

When you have those freezes, note the time and have a look at your secondlife.log file (c:\documents and settings\<username>\application data\secondlife) and check if you have an entry at that time about LLTextureCache::purgeTextures there with a pause in the timer.

In my latest viewer I have changed the cache handling (http://nicholaz-beresford.blogspot.com/ ... version BE-o), if you like try that and give feedback if it fixes it for you or not. There is also a blog entry (http://nicholaz-beresford.blogspot.com/2007/09/30-sec-freezes-redux.html ) with things to check when it happens.

Intel Dula Core
Nvidia 7600
2 GB

This needs fixing as it is hard to perform the most basic of functions

CPU: Intel Pentium M Series Processor (599 MHz) [note: this is wrong, it should be 2Ghz, but SL misreports it for some reason]
Memory: 1024 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: FireMV 2400 PCI DDR x86/SSE2

Since installing build 1.18.3, these freezes have taken on almost clockwork regularity. About every 20 minutes I freeze up for 5 to 10 minutes. Functionality is basically nonexistent: if I am lucky enough to have sittable surfaces in the general direction my camera is pointing, I can move by sitting myself from place to place, and that's about it. Strikingly, while fps crash to 0.3 or less, bandwidth is seemingly unaffected; indeed, bandwidth will often decrease markedly as I UNfreeze. Nothing seems to correlate with the freezes except time: they happen in busy regions and empty ones, while flying, walking, turning, sitting, or falling (I'm not kidding, I've had it while skydiving from 6000 meters into an empty island sim). The only correlate seems to be the time elapsed since the last freeze--a regularity that suggests strongly that some kind of scheduled housekeeping task is at the heart of it.

This bug is so brutal. I work full time in SL and it's seriously screwing up both my deadlines and sanity. My problems are exactly the same as mentioned above. Have never had a problem on this computer with SL before, not like this anyway.

This bug is still a serious showkiller for me (:

Lisa keeps clearing her cache

Various websites say this should be safe to disable.

This bug is still a serious showkiller for me also

I am putting out a request as a follow up to Phoenix Linden's blog comment on Sept. 18th, 2007: http://blog.secondlife.com/2007/09/18/second-life-url-handler-exploit/#comment-479517
In reference to Lex Neva's comment:
http://blog.secondlife.com/2007/09/18/second-life-url-handler-exploit/#comment-479385

Keep the pre-voice 1.18.0.x viewer branch alive for builders
http://jira.secondlife.com/browse/VWR-2700

Votes are welcome!

Doesn't happen every time I swing the camera, which I do all the time. But happens at least once every few hours, and it results in a crash (infinite hang, more than minutes). Draw distance is 64 or 96, all my system can (barely) handle.

However, it could be related to voice.. I did tend to have voice off for a while, and have had it on more often recently. Yet I don't remember the freezes happening before clearing my cache.

CPU: AMD (Unknown model) (1808 MHz)
(It's a dual core Opteron 165)
Memory: 2048 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7600 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.1
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)

I would drop to 2 - 3 FPS when ever i moved or or panned and zoomed. SO this morning i turned off the Enable OpenGL vertex Object and i am now back to 15fps, still crashing every hour or so, but at least i can camera and move better

I have recently bought myself a new PC, M2N - E SLI series. Not going to put all my specs cause thats not the issue. The issue is funny enough the sound hardware. SL worked fine for me untill i got the new pc, so knew it was something to do with this one. When going into sl, everything else freezes, mostly sound devises, but sl seem to work EXEPT voice. So that lead to disabling voice, and there works SL. Checked out a bit with my sound driver wich is the CM6501 sound device. I installed new driver tonight, and there i go, everything fixed.

Now this works perfect for me, SL is fixed and i can use voice again.
ftp://dlsvr02.asus.com/pub/ASUS/misc/audio/c-media/ <<The link to the driver since i had a hard time finding it. It is the CMedia6501_Audio_V51281802_XP.zip file.

Once again, if this have nothing to do with this thread, or if this does not solve people's issue with second life, im sorry for the wrong post.

We have already come to the conclusion that the Voice code is not what is causing the render loop to freeze. On the other hand, before the voice release, there used to be a bug in which the client would eat up most of the system memory over a period of running. This bug seems to have been fixed, but it's fix may have broken something else in the 500,000+ lines of code that make up the client. What Vinhold and I suspect is that data (whther texture, or prim,) is being removed from a list in memory, or on disk, and not removed from a "already downloaded" list. Neither of use know enough C/C++ to determine what is going on in the code, and I have yet to be able to successfully compile my own client to do some testing.

I spend most of my time in or near a sandbox area (Skybeam Estates) and I have been able to predict some of the conditions when my client is going to lock. This is not to say that I can predict every lockup, but I know when MY actions are highly likely to cause a lock. Here is a list of the conditions as I know them:
1: Be in an active sandbox area. (This needs to be tested... I don't know yet if lockups can happen when the client is nowhere near someone who is building.)
2: After looking around and letting everything get downloaded and stable, point the camera in one direction and DO NOT MOVE the camera for 5+ minutes. You may script, move the mouse, write notecards, chat, etc. but do not move the camera or the avatar.
3: After the 5+ minutes, rapidly turn the camera around.
4: The client should freeze for anything from 1 second to several minutes.

If I could get some people to test these steps in/near sandboxes, and in areas that have no other people around that would be good. Just mention the sim that you were in, and what client and version you were running.

I also don't know if the Windlight Firstlook viewer is plagued by the same issue. I shall be testing that soon.

Vinhold and I are also in communications with James Linden for his most valuable input on how the client works internally.

Cron

There is something external which affects this - some days are worse than others: one day can be completely fine; but when you do start getting this, nothing (rebooting, reducing graphics settings etc.) seems to reduce the problem. Hence I wonder (purely circumstancial evidence I'm afraid), if lost packets due to lag acts as some some of trigger!

Can I stress that this is a BLOCKER for anyone experiencing this! Yesterday, I couldn't run the client for more than about a few minutes before it locked up, and basically I had to give up on SL for the day. If this isn't fixed soon, I may just give up on SL completely as it is just NOT USABLE. I certainly have not been able to do ANY in world creation since 1.18.0.6 ceased to work!

I suspect many others have already left SL permanently over this issue..

This problem should have the HIGHEST priority within LL - much as I applaud Vinhold and Cron's activity, the developers in LL should have already have been doing this sort of logging and analysis!

I realise that this is not an easy problem to diagnose and track down the source, but this really does need an IMMINENT fix!

I guess there are various ways of freezing, but whoever suffers from them might want to try my viewer (either the OldSchool (based on 1.18.0.6) which still runs or the newer BE-s or BE-t which some users report to have fixed the freezing for them).

http://nicholaz-beresford.blogspot.com/

Pity, much as I would like to recommend SL for some fairly high profile VW projects in the pipeline, I can't as things stand.

It looks like I had meant to close that bug myself but for some reason didn't, so thanks... but... for future reference, you should only resolve other people's bugs, not close them.

These crashes are (at least sometimes... I don't know for sure because every other program slows down and hence it is difficult to access the secondlife.log file) associated with a basically infinite number of "LLAudioChannelFMOD::cleanup error: An invalid parameter was passed to this function" errors... several of them every second. The happens even when i have voice disconnected.

This happens with all viewers. I am running MacOsX 10.4.11

Second, I didn't see any information that specifically associates existing behavior with voice. I may have missed it though, see the above comment.

There was a bug associated with voice causing the client to lock up, but we have not been able to reproduce it internally, so we have closed that bug.

We are aware of some occasional slowdowns in the client that are difficult to solve; we are working on fixing these but it will take some time.

If you are seeing severe lockups where Second Life becomes completely unresponsive, please verify whether or not these occur only with voice enabled. Either way, please create a new bug (since a lot of code has changed since this bug was first filed). Please include hardware specs in the comments and attach log files; keep the comments brief so I have time to read them (keep in mind we are tracking hundreds of other bugs also).

Thanks,
-Steve

The comments are long as in lieu of any positive actions from LL on this problem, many residents have tried to work out where the problem may lie - there are a number of false trails here however.

I am changing the status to Won't Finish rather than Fixed Internally, as this issue is not fixed (just experienced this under 1.18.5 RC2).

If this is still being seen in recent releases, it's the cause of much resident pain. Based on the comments above, it looks like it's been the cause of a fair amount of Linden pain, too.

Various combinations of jpeg library / opengl library and the viewer can cause this, it is also system specific.

I have seen viewer 1.18.3.5 working ok, but 1.18.5.2 dying in minutes with the same libraries on an AMD64 (linux) but another user with same combination on powerpc has no trouble.

In my case changing the jpeg library to a newer version has fixed the bug for me for 1.18.5.2.

All i can suguest is if you see this try swapping between the two jpeg libraries KDU and openjpeg and see if that makes a difference.

if you are experienced and not afraid to mess up your system :-
Also try upgrading/downgrading your openGL drivers (probably part of your graphics card package).

There is a really subtle bug here somewhere and its not necessarily the fault of the viewer in all cases, it shows its self differently on different systems so its an absolute nightmare to chase.

As in solved? I don't think so! I agree with Matthew on this.

Quote Steve Linden: "Second, I didn't see any information that specifically associates existing behavior with voice. I may have missed it though, see the above comment. "
Answer: This is wrong. It was since - as we just easily call it 'the voice viewer' - appeared. As stated before already, I am not using voice at all.

Quote Steve Linden: "We are aware of some occasional slowdowns in the client..."
Answer: This is not a slowdown. The whole client just freezes. From a few seconds to several minutes. Often resulting in a loss of connection with the server and a forced relog.

Quote Steve Linden: "...please create a new bug (since a lot of code has changed since this bug was first filed). Please include hardware specs..."
Answer: Again??? All info is here already! Why create a new one? My info will still be exactly the same! Also used all the RC-candidates right as when they appeared. Still no change. If the code has changed and when it would affect this bug, showing a different behaviour, I would have let you know and/or closed it myself. But this bug did not change at all. It is still there and still exactly the same.

If these are 'reasons' to close a serious bug that affects many for a long time already, I start to wonder how other bugs are 'solved'. Need more info then everyone already is handing you? Fine! Just ask. We'll most likely burry you in tons of debuglogs. We even help you dig! But this is a rediculous way to close a serious SHOWSTOPPER. (If I would tell my RL clients their reported problems are solved because I closed their report about it, I would be out of business pretty soon...)

I vote for reconsidering this and reopening it. Actually the only right thing to do.

Kind regards,
Lisa Lowe

Note: If this bug is hardware related (wich would not surprise me, looking at the different responses), tell me what to look for. Is it my videocard that can't handle the huge amount of data? Is it the powersupply that causes things to lock up? Does my harddrive not respond quick enough somehow? Is my CPU locking up because of some wrong type of data to process? Is my RAM too slow? Maybe create a little testprogram that put things to the limits SL requires to run smoothly, given the chosen settings? That might give everyone an indication if their hardware is the cause of all this. Then we have two options. Spent serious money on upgrading the hardware or (optional) decrease the strain that SL puts on systems.

1.18.5.3 was just released, Windlight version 1.18.5(74642) also was just released. If you are experiancing this issue in either version, open a new ticket and link to this ticket as "related". Be sure to specify which version (release or windlight) this is happening with.

Things to make note of... Anti-Virus software, and which version you are running. Are you logging Chat and IM's, are those files large?

For information, in case LL are interested, the problem is as bad as ever with the latest Windlight and RCreleases.

If Henri's log is causing problems it is surely not beyond an administrator of jira to cut and paste it into a text file to attach to the issue, and delete the offending comment.

This problem is NOT fixed so I am re-opening it.

The problem occurs exactly as decribed in the description in both latest released version 1.18.5.3 nor in Windlight 1.18.5.74642. If effects all versions of the viewer since 1.18.1.

It happens despite switching anti virus off.

It happens whether chat logging is off or on, and even if the log directory is empty.

It happens whether voice is enabled or disabled.

Henri Beauchamp - 08/Oct/07 04:11 PM:
Today, I have been experiencing freezes every few seconds the whole evening:
I never had such bad an experience with SL so far !
The said freezes seem to occur as a result of out of order packets receives ("ch
eckPacketInID: packet_out_of_order" in the log), and I must "iconify"/de-iconify
the SL window several times to try and "wake it up" (the SDL iconify calls in t
he log). Below is the log of a short session with many freezes:

In response to a question noted above – in my case, there are NO chat or IM logs at all, ever, and only whatever debug logging the SL viewer creates by default. This really looks like a poorly-prioritized garbage collection process of some sort, but then again, I am only an egg.

I suggest splitting this task into sub-tasks, including one for the already-fixed bug, and make new cases a new sub-task. (Or, make this task a sub-task of a new one.)

In any case...
Coyote, I suggest attaching your debugging log somewhere (either here or a new sub-task), after you experience a freeze and before you quit and log on again. You can usually find it (if you're in Windows) at C:\Documents and Settings_YOUR WINDOWS USERNAME_\Application Data\SecondLife\logs . (t's named "secondlife.log". It'd also help to give an approximate time when the freeze occurred, so people know where to look in the log.

Windows 2000 Professional
Core 2 Duo E6550 (2.33 GHz)
2 GB DDR2-667 RAM
nVidia GeForce 7900 GTO

I get this all the time. However, the client only uses 50% of my processor power; that's all it EVER maxes at. It can't go past that, because it's not properly threaded (even with the "run multiple threads" option in the rendering menu in the client menu) (at least this allows my other Windows programs to run uninterrupted..). I bet it would perform alot better if it was properly threaded, but that's a different topic. Point is on my dual core system it can't reach 100% even when locked up, only 50%. This allows easy termination when it doesn't unfreeze, which happens rather often.. I'll often wait quite a while before terminating it just to make sure it can't return me to the game, after which without a doubt I'll be logged out (after likely being caged, orbited, and/or deformed (or, they could file an abuse report on me.. That's what I want to see when I come back after crashing.. A message saying I've been banned.. Yeah..) by whoever the hanging game caused me to plough into).

Besides it not going up to 100% my issue is exactly the same as the issue being discussed here. It seems to crash mostly when I look around after I've been looking in one direction for a while, but if someone builds in my field of vision after a similar inactiveness then it will hang quite similarly. It's a huge turn-off, and interrupts me at very inconvenient times such as the one I described several lines up.

Disabling Object-Object Occlusion (requires client restart) seems to cause the client to crash under certain conditions. That along with the fact that it boosts performance when enabled (and it apparently doesn't work around the problem for some people), means that it should be nothing more than a temporary fix.

Come on, this problem happens to nearly every Second Life user there is, we can't just ignore it and try to learn to accept it as an inevitability. This has been occuring alot longer than it should have been. Apparently even the 'Winter Festival' has a higher priority than this.

Phantom, Intel Processors are hot over 65 or 70°C. NVIDIA graphic chips can handle a lot more (I'm not entirely sure, but I think I ready they're still doing okay over 90).

Also, one time when it crashed, I opened task manager and saw SecondLife.exe still in memory and it had an ever-increasing memory footprint instead of shutting down completely.

AMD Geode NX 1750, 1 Gig ram, NVidia GeForce NX7600GS 256MB
Windows 2000 pro SP4, Graphics: Nvidia 9.1.4.7
Viewer: Nicholaz BE-v 1.18.5(3), Voice off, A & V streams off, ViewDist.:96m, RippleWater off, Vertex shaders on, bumpmap on, avatar vertex on, locall lights on, Terrain high, Object & Avatar mesh detail: Max, Flexible & Tree mesh detail: 60%, Anisotropic: off, VBO on

Seems SOMETHING was finally fixed SL Server-side that had a tremendous impact on the ability of the current viewer to function normally again... just like the good ol' SL days. Yay!!

I'm really impressed with how you do this, LL. It can be anything from 10 minutes to 10 hours of use, but the at that precise moment when that important task comes up: BAM! Freeze to death. And not just once, usually two or three times in a row. Any other times the freezing can be zero to mild ( ~ 5 second pauses on average, going up to 30 secs sometimes).

There must be a repro for this. Something like:

1. log in and do some mundane things for several hours. Teleport around, go to high build areas.
2. Observe regular freezes, as reported by everyone. Sometimes, if lucky, none are observed.
3. Continue anyway.
4. Have something important occur that might have drastic consequences if you're unable to attend to it – a griefer appears, you start an IM with someone important. (note: regular IMs won't cause this. they have to contain some special info or require special attention)
5. observe the viewer chokes on itself and freezes to death faster than you can say "OH BOB SAGET!"

Great work I think if you want a solid repro of this, just try to find the most genuinely important thing you need to do, and then try to have it occur randomly during the time you're NOT testing for freezes. If it's genuinely important enough, you should find the viewer hangs on cue. Even if you're not moving around at all!

Every once in a while the viewer freezes for upwards of 3 minutes. Sometimes it recovers and all is normal again. Sometimes no motion is possible, viewer is "Not Responding". It clears and I can rotate, but not move. After a short interval, the minimap goes red.

Have had this issue using all viewers right up to 1.19.1 (4). Trying the new 1.20.0 right now to see if this has the same issue on my machine.

(1) the issue still occurs with 1.19.1.4 and may in fact have deteriorated even as peak fps in that version have increased

(2) running two copies of the SL client (of different versions) simultaneously reduces the deepest troughs of freezelag (that's not a typo). Peak framerates decrease, but at the same time, the lowest framerates improve.

For (much) more detail, see VWR-559

CPU: AMD (Unknown model) (3013 MHz)
Memory: 2048 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9600 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.15422 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 193/9484 (2.0%)

edit: CPU is AMD Athlon 64 X2 6000+

Any thing written to the log during/just after the freeze, if you call up the debug menu and watch the output console when the freeze resumes what do you see? There are some old favorites such as texture cache clean out taking too long and causing a stall and the processing of appended ACK's taking too long due to a DNS taking a while (which in theory should not happen on the linden viewer due to c-ares)

The debug console is just telling me

INFO: display_stats: FPS: something between 2 and 100

No further infos while, before or after lagging.

Texture console telling me that it's not loading any textures. Happens as well in void sims while just standing.

I'd recommend finding someone this is happening to a lot whom you can also trust to do the job right and hooking them up with packet logging software and keep an eye on the network 'twixt client and server.

http://blog.secondlife.com/2008/06/25/now-available-optional-release-candidate-viewer-120-rc11-dazzle-we-hear-you/
http://secondlife.com/support/downloads.php#download-Testviewers

BEST NEWS ITEM EVER

EDIT 16/Jul/08: After spending much more time on this viewer, up to RC14 so far, I've noticed that it does in fact still suffer from freezes while looking around. However, it is not as frequent as before. Definitely improved.

Three indefinite freezes so far today, and counting. Yet none before that since around the time of RC11.

I'm noticing freezes when blue friend notifications appear/disappear in the bottom right of the screen more than I used to, and I always noticed that the viewer tended to freeze up if was about to display a tooltip for an object or about to be moved or even just have the mouse come close to an interface element sometimes. Moving the camera is definitely the worst culprit though, and gets progressively worse over time as some have already mentioned.

And finally, it may be worth noting on the Mac viewer that the video memory slider in Graphics prefs keeps resetting itself to 256MB (I have a 512MB GeForce 8800 GT). Doesn't happen on the Windows version. I'm just wondering if that slider is at all related to how quickly the freezes start? I can't set it to 512MB to find out because it just resets itself again when I re-open the viewer.

By the last few comments, I do see that some freezing is still reported since this fix, and I do not mean to diminish that. However let us please open a new bug to report & track new freezes on this hardware. Because this original report is against the 1.18.2.0 code, it is extremely likely that freezes still seen in 1.20 are now the result of other memory bugs. It will only confuse further investigation to tie such reports to this original investigation of LLMotionController.