|
|
|
Me too. And its really annoying. what I have had to do to reduce the freezes is set my draw distance down alot, this cut down the freezes but does not stop them. what i have also noticed is that it only happens to me when I disable camera constrants. beening a builder of large structures this is a must and i can not work this way with the camera constrants on and flying around to get to parts of my build.
The machine Im using is a Pc dual core AMD 5400+ , 2GB RAM , Nvidia 7600GT , running XP Pro ( fully updated) I've seen a few other issues like this, and have experienced it myself. Annoying! This sounds like
Just a FYI, this is happening on Mac OS X too. Running latest viewer here and it tends to happen mostly when panning around.
I am also seeing this issue... Dell Inspiron XPS 3.4 GHz EE, Windows XP Pro, plenty of RAM, didn't do this before the last couple of viewer updates...
Having the exact same problem. Happens to me 2-3 times an hour, for between 10-30 seconds on end.
REALLY irritating, AMD X2 4400+, 2 GB, geforce 6800 GT. im a builder. the hangs range from a few seconds to long enough that i relog because of it (>1 minute), and often a few short hangs happen in a row. it seems to be triggered by camera navigation. i use disable camera constraints.
during the last update, I used to crash close to every 5-10 mins. With the latest update, I no longer crash, but I do get lockup anywhere from 5 seconds to a minute.
I am on a Dual core 2ghz with a Geforce GO 2 gb ram. The NVidia pattern was noticed on the forums too. NVidia 7950 GT here. Yesterday was hell, freezing up temporarily, locking up permanently, ctrl+alt+deleting my way out of Second Life...before I discovered alt+tabbing to a different application (usually my internet browser) for thirty seconds was enough to unfreeze it, allowing me to return to work without relogging. Scratching my head as to why it's not been happening so much today.
CPU: AMD (Unknown model) (2010 MHz) (Dual core)
Memory: 2048 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: Radeon X1800 Series x86/MMX/3DNow!/SSE2 OpenGL Version: 2.0.6012 WinXP Release LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) Packets Lost: 0/88622 (0.0%) Viewer Digest: f1e1acae-ab67-4275-2612-009581afe071 Noticing that there are a lot of people with dual core cpus here. Maybe it's a dual core specific problem ? Helwett-Packard Pavillion 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. i saw a freeze happening while disable camera constraints was not used. so disable camera constraints is not required for the bug to happen. but i was navigating with my camera.
Intel dual core 3.015MHz CPU : Asrock motherboard : ATi graphics X1550 256Mb: 2Gb ram 4Mb connect. All drivers updated : XP pro SP2 O/S.
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. Just added log entry for that period of last freeze
2007-08-16T14:13:10Z INFO: LLCircuitData::checkPacketInID: packet_out_of_order - got packet 45005 expecting 44958 from 72.5.13.18:13004 Definitely seeing this when disabling camera constraints and building on a "SIM" level. Set draw distance to 256 and pivot the camera around the SIM a bit.
The whole client "freezes" as if the windows process is about to crash for 20-30 seconds. Using dual core here. Assigning the executable to a single processor AFFINITY seems to mitigate it some, but does not eliminate it. Since disabling voice on my estates, i haven't had this happen all day, I will comment again tomorrow with an update
I am experiencing similar issues, but i also notice complete loss of bandwidth data stream requires i log out then reset my router/modem then restart pc (dell 5100 XP pro fully updated ATI RAD card duel core AMD etc etc 4mb connect no other issueswiv pc) I also tend to lose my LAN when this happens so I unplug cable and plug in to kickstart LAN connection...Latest version viewer 18.1.2 never happened before....losing faith ....it happens when i am in normal activity walking normal view sitting chatting etc just happens after bout 5- 8 mins after log in..for the first few mins life is good but then ALL STOP.....
Same problem on 2 computers with Vista and XP, Wifi and Ethernet.
I have "LLCircuitData::checkPacketInID: packet_out_of_order - got packet ..." too CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
Memory: 2027 MB OS Version: Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8600 GT/PCI/SSE2/3DNOW! OpenGL Version: 2.1.1 NVIDIA 100.14.11 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) Packets Lost: 101/2632 (3.8%) Viewer Digest: 43df0268-55b0-d259-b7d6-12c8061926b2 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. Looks like this issue had been seen and reported in the Firstlook viewers (just linking another one) but not addressed before it went live!
I suspect that the out of order packets are a symptom not a cause.
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? P.S. the other reason I suspect the problem happens within a driver rather than the viewer itself, is that I still get the computer freezing with 100% CPU usage even when I run SL on a Core Duo with SL locked to only one core!
OK, I've reverted to 1.18.0.6. Generally this client feels far better and smoother in terms of performance, delivering much better FPS, whereas in 1.18.2, it often feels sticky due to poor FPS.
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? to summarize, freezes happened:
I think you're all possibly making this too complicated. I've experienced such lock-ups since I joined SL back last November. They've gotten worse as concurrency has risen and with updates to the servers and viewer – no idea which is at fault, though, if either. It used to be that a lock-up would only last for a few seconds. I recently waited out one that lasted nearly two and a half minutes – just to see if it was a lock-up or a crash. I've experienced this on three very different computers and on several different Internet connections. Hardware doesn't matter. Software settings don't matter. This is as annoying as the rising severity of lag, even in sims which didn't experience lag only a few months ago, and I wonder if this is actually a lag-related condition.
Amanda,
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? I was experiencing the exact same problem as Beware Hax is describing it: Freezes during camera navigation, rotating the avatar (including mouselook), etc. I have two systems with ATI and Nvidia cards. Both of them were affected in the same way.
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".) Object-Object Occlusion can be switched off via the debug menu (under Rendering - also via CTRL-SHIFT-O) so it may be worth trying that on Windows and Mac, and see what effect that has? As far as I can tell setting LL_GL_BLACKLIST=l on Linux switches this off.
The object-object occlusion menu entry works as well. Thanks for pointing this out!
After disabling the option, a viewer restart is required for the setting to take effect. client hung for "minutes" and i restarted it, even though i had the object-object occlusion option disabled. so far, during days, i only had one short hang, instead of a hang every few minutes.
Likewise - disabling object-object occlusion reduces the frequency and impact of the problem but does not totally eliminate it. As the occlusion code doesn't appear to have been changed, it seems unlikely that this is the cause.
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. Neither disabling object occlusion, nor disabling voice, has done anything to help at all for me.
I haven't seen this issue at all.
CPU: Intel Core 2 Series Processor (2394 MHz) i am having similar issues, with this latest viewer, it appears to be the voice viewer only though, as i don't have these problems on the pre-voice viewer that i run occasionally on a different computer.
environment: winxp athlon64 x2 3600+ 2 gigs ram 256 meg ati radeon x1950gt 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. Have been experiencing this intermitantly for past 10 days or so but tonight has been awful. At least 15 freezes lasting from 10 to 60 secs and three others where it was clear the PC was not going to recover & I had to re-start the machine manually.
Dual-core E6600 nvidea 8600 GTS openSUSE 10.2, dual core AMD Athlon cpu
ATI Radeon X300SE (latest ati drivers) 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. Same problem here, almost always when in sandboxes, even when not building myself and very very rarely elsewhere, not even in huge malls with loads of items and textures loading.
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. Soft Linden also noticed something similar to some of the above comments; part of his observations are: "Moving the camera around a lot aggravates the problem, making it more frequent still, to the point where I can make the desktop spend more time frozen than moving."
Definitely happens on the Mac viewer too. I get it very often.
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. I have been dealing with this issue for a while now as well with the new viewer. So convinced was I that it was my puter and not SL that I rushed out to buy a new puter..; ). The addiction must be fed lest it starve to death...
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 first started noticing this viewer freeze bug with the voice firstlook viewers (before the main viewer added voice).
I have been told by others that disabling voice seems to reduce the frequency and duration of these freezes, but doesn't stop them. This happens to me constantly - particularly when using camera controls. Sometimes I need to completely kill SL to un-do the freeze. Turning off voice helps maybe only slightly.
Specs: This is extremely annoying! Freezes seem to develop into longer cutouts each time. Only have had this since the voice update.
AMD FX-57 OS Version Microsoft Windows XP Professional 5.1.2600 Service Pack 2
BIOS Version Version 1.30 CPU Intel(R) Pentium(R) M processor 2.00GHz Memory 1024MB RAM Hard Disk Capacity 119,916,357,120 [Byte] 111.681 [GB] Hard Disk Free Space Capacity 108,702,674,944 [Byte] 101.237 [GB] Video NVIDIA GeForce Go 6600 ver=7.8.8.2 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 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 1.18.2: This issue has become critical and renders the viewer nearly useless. This "freeze" occurs WITHOUT voice enabled, and as of 19 september, occurs at least once every 10 minutes. I've heard the same thing from many other users.
I am having the same problem, and as Oryx says, it has gotten substantially worse since the most recent update.
For me it is not a heat problem - my fans aren't even going in my system and my air temperature is only 63F. It's a viewer and graphics card problem I believe but it's hard to reproduce when it happens so often. I find it's particularly bad in heavily textured areas - for example Downtown in Varado sim; Retrology sim; Midian sim
Im having the same "pauses" in the latest 1.18.3.4 RC too. They can be from 3 to 15 seconds long. When it happens I can switch windows and see SL shows "not responding"
Also seeing it (and have been for sooooooo long) on three different systems:
Desktop #1 Desktop #2 Laptop #1 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/ I have had these kind of freezes before, but a just like the others a while ago they came back. Hard to pinpoint when they came back though.
I concur with all the above reports. Constant freezes when camering or zooming.
Intel Dula Core This needs fixing as it is hard to perform the most basic of functions Linked this to VWR-559, which seems to be essentially the same issue except that it crashes the client (since the crash does not take place immediately, it may simply depend on whether the network can stand the wait).
CPU: Intel Pentium M Series Processor (599 MHz) [note: this is wrong, it should be 2Ghz, but SL misreports it for some reason] 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. I installed Nicholaz Beresford's client and have been using it while building, and lots of cam movent because of it and so far the freezes are gone.
 CPU: AMD (Unknown model) (2188 MHz)
Memory: 3327 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.0.3 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) 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. A few viewer updates later I still experience this problem. I constantly use the latest RC viewers (1.18.3.5 now). As mentioned before, to me it often happens also while panning around. But also when I just turn my avatar. Often on HIP it happens if the giant green Exit sign comes into view. In other places I have it also with heavy particle sources. Maybe there is a relation to particles? But on the other hand it still also sometimes happens while building in very quiet places.
This bug is still a serious showkiller for me (: Lisa keeps clearing her cache Shutting down the "NVIDIA Display Driver Service" on Windows seems to make a big difference as regards the problems I was having.
Various websites say this should be safe to disable. Come on Lindens get to the bottom of this one please. or at least lets have a choice of viewers, voice or non voice. It's been well over a month now and still no fix. The old pre voice viewer 1-18-0-6 did not have this issues and now we all have to use this horrid voice viewer. I now spend just as much time waiting for it to unfreeze than doing anything else. when it does unfreeze i go to move the camera again and bam another 2 minutes waiting.
This bug is still a serious showkiller for me also Freezing almost every times I try to pan the camera around in a significant way here on a Mac Powerbook.
I can't build like this. Everything was running smoothly on 1.18.0.6... If you can't fix this please give us back 1.18.0.6+ so builders can work. It seems you made us upgrade simply for a "URL Handler Exploit" which didn't even affect me personally as a Mac User. 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 Keep the pre-voice 1.18.0.x viewer branch alive for builders Votes are welcome! Thanks for the additional info, we haven't forgotten about this (it causes me troubles daily) and I'm asking development for an update.
PowerBook 17" 1.67Ghz/2GB 3Mbps DSL
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. I'm sometimes experiencing a viewer freeze when panning/turning/moving/etc. the camera.
I do not remember having this issue, until I cleared my cache. After that seems to be when I began to experience it. I was using an older version of the client when it began to happen. (Sorry, I don't remember which version it was.) I since upgraded to 1.18.4 (3), and still have this issue. 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) Only a minor add, it's not exactly reproduceable, but it does seem to happen mostly during mid camera pan for me. That being said it also happened last night while I was just sitting still watching myself and typing in chat. If you're looking at a basically static scene at the time it sometimes just appears to be a massive chat lag.
I'm also slightly bemused with the connection to the voice client introduction. Yes the problem may have started around then, but I'm using Linux which has most of the voice code absent (afaik), and it still happens fairly regularly. I don't know if this applies, but after loading the new nvidia driver, nov 6, 2007 verison, and uploading the new client on:
CPU: Intel Core 2 Series Processor (2660 MHz) Memory: 2046 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7950 GX2/PCI/SSE2 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 Ok now i dont know if this is really fixed but sure worked for me, hope it does for other. If not, post this to other people if they may experience the same problem. The problem lies with if u have the CM6501 sound device.
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. 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 haven't forgotten about this and I was reminded of it when Dan Linden commented he was having continued problems in 1.18.4(3). Thanks for the most recent comments and votes (with 111, this definitely is a HOT issue).
Vinhold Starbrook and I are actively working on a hypothesis on what is causing these lockups. I am running the Linux client, so I modified the startup script and added a watchdog program so that I could create log files with markers at the lockup times. Now I just need to read the logs.
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: 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 still experienced in the voice client, I'm afraid.
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! Agreed with Matthew. It's nearly impossible to cam or move these days. I noticed a slight improvement with 1.18.4 but it's SERIOUSLY back with a vengeance with the 1.18.5 Release Candidate. Fix this please!!! If it's okay with people I'm escalating this to "Show Stopper."
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). Another week, another windlight update, but still no resolution or even any hint of progress with this problem, so another week unable to do anything productive in SL.
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. Oryx,
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. I think I get this one occasionally. It manifests itself for me as an extreme slowdown in the processing of key and mouse clicks... every so often, instead of taking a microsecond to register a click, the client tales several tens of seconds or even several minutes to act on the click. Ironically, if I get disconnected from the server the client appears suddently to be running at normal speed again (although if I try to interact with anything and/or chat it becomes obvious that I was disconnected.)
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 First off, putting log files into a comment makes a task like this very difficult to read through. Please attach logs.
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, Resolving this issue as it has become too confused and the original bug reported was fixed. See above comment.
I'm actually quite annoyed by this. After months of suffering from this problem, and reassurances by Torley that LL were aware of the problem and indeed this had been seen by people within LL and it is a "hot topic", the issue is summarily closed by someone who hasn't even read the description properly (it is not associated with voice - see the description "I have voice turned off (not using that at all)", it has however been a problem since the Voice Firstlook code as merged into the main client in 1.18.1) on the basis the comments are too long!
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). I agree with Matthew. This is an ongoing, major problem. I'm VERY upset that this issue has been closed by (who? Steve Linden? Who's that???) LL. I could say that pretty much every single user of SL experiences this problem, at least every single user that I've ever talked to. It happens while camming, while moving, while building, it's just absolutely ridiculous. To close this issue because "it's too confusing to read" is complete and utter bull honky.
Sign me up as also wanting the "won't finish" status of this to be revisited. I personally haven't seen this since I started using the 1.18.5 RC viewers but it was just-plain-evil for the months before those came out. (and, for the record, I have never enabled voice on any viewer)
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. Just like to post a recent discovery, but it may be quite obvious to some.
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 :- 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. Closed?????
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. " Quote Steve Linden: "We are aware of some occasional slowdowns in the client..." 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..." 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, 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. Open a new issue on the matter, as steve says.
This has not been solved, hence it is to be reopened.
Steve's comments were ignorant and showed users only another example of sloppy reading. Putting this back to the resolution Steve Linden placed it.
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? In most other software projects, an issue is closed when it is resolved. It isn't closed just because there is a new release, in the hope the problem might have gone away, and then a new issue opened on the same problem if it turns out not to be the case.
For information, in case LL are interested, the problem is as bad as ever with the latest Windlight and RCreleases. Sorry, I cannot see the point or reason for creating an exact duplicate of this problem and having to re-vote/re-watch the exact duplicate - especially as anyone working on the problem would still need to consult the information in this entry.
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. Adding Henri Beauchamp's comment as attachment.
Henri Beauchamp - 08/Oct/07 04:11 PM: Removed Affects Version/s of "First Look: WindLight" – as it says when you're editing an issue, "ONLY select a "First Look" if this issue ONLY affects that version." We do this to better focus on FL-specific issues. Thanks! i experienced the freezes on 1.18.6 today, after i hadn't gotten them for a few days
There's no question that this problem continues in the latest releases to date – pretty much exactly as described above by britney benford - 25/Aug/07 03:55 AM. This includes the latest release 1.18.5.3 as well as Windlight 1.18.5.75173 (Windows XP versions). At random intervals, but generally more often after being in busy areas for a while, the viewer will freeze entirely other than mouse motion, usually but not always with a UI hourglass shown as as mouse cursor, for 30-60 seconds. In EVERY CASE – I've been watching carefully, lately – the disk access light flashes furiously during this entire interval. Then the viewer comes back to life, with any UI clicks or typing that were carried out "blind" in the meanwhile THEN carried out by the viewer. And it operates normally again.
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. Although I understand the sentiments in reopening this issue, it's not really useful to track things by symptom. It's a lot more useful to track of things by their causes.
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... You've got my vote, I need this fixed.
Windows 2000 Professional 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. For the record, my video card is not overheating. Right at this moment the game is still hanging, while my video card's reported core temperature is 54~55 degrees Celsius, well below the 110 degree throttling threshold (yeah I think that's a pretty high threshold too, but it's not changeable..).
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. Okay, fine. Can we get this tested / verified for implimentation queueing then? That texture culling issue Nicholaz is reporting sounds valid all right, because often the lockup is accompanied by my hard drive churning like it was making butter.
Phantom: By the way, you shouldn't check the temperature when the client has already hanged, as the graphics card (probably) is no longer receiving any work from SL. You should check when there's actually activity still occurring.
55 degrees sounds like an idle temperature to me, to be honest. (Also, 110 degrees might also be just the "OMG I'm gonna burn up if I don't throttle" temperature, and the one where errors start occurring is probably a bit lower... ) Celierra, really? I thought that was plenty warm already, I haven't seen my video card's temperature go above 56 and I often look I often look at the temperature while playing Second Life (not just after hanging). This is the first video card I've had that can tell me the temperature, so perhaps it is just quite good at cooling. It uses a second slot just to be able to fit it's heat sink and fan, which vent out the back of the computer.
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). When I first installed 1.18.6 (77495) (Second Life WindLight) and went a few hours withoug any kind of freezes, I thought it was fixed, but then it started getting more and more freezes for longer and longer times.
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. I am wondering if this is the same freeze issue as I have.
I freeze at places where a lot of textures need to be loaded but most clear are the different timed freezes when in edit mode, I want to change a texture and call the texture window of an object(side). Also I get freezes upto a full minute when choosing "person chooser" in like by example trying to set a specific name to sell land to. It never makes me crash but just stops everything in the viewer. AMD Geode NX 1750, 1 Gig ram, NVidia GeForce NX7600GS 256MB Wow! Last night after the so-called Rolling Restart... I was FINALLY able to log in with the latest Standard SL Viewer and there was no more Camera-Panning Crash or video lockup EVAR. And I went to some of the usual SIM Crash candidates and Sandboxes. Every one of them which used to choke up the SL Viewer for the last few MONTHS... was suddenly clean, quick and I couldn't make the Viewer lock-up as it normally would after a few minutes, no matter how much I tried to PAN and PAN without camera constraints.
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!! Except they rolled back the server change.
I disabled the popups that show friends loging out. Also i noticed that the network times out like crazy. My friends never appear online. Im guessing this is some sort of network script out of wack.
Hi there, Since a month back I have started experiancing freezing when someone goes online or offline, when people talk to me in main chat, When people IM me, when people go on voice, when I open my inventory, when I watch a film, when people use special affects. The freezing lasts from up to a minute to five minutes and usually results in me crashing or having to reboot my computer due to an all out freeze.
You gotta hand it to LL for the amazing technology they've implemented so that the viewer will run fine for hours and hours and hours and hours, and yet the second you need to do something important like ban a griefer from one of your sandboxes, or hold an important IM conference with a client/friend you haven't seen for months, the viewer completely freezes up until terminated, on cue. At any other time it will run for ages problem free.
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. Great work This is likely to only help some, as it seems to me looking through that this JIRA in all likelihood covers a number of related and unrelated bugs. BUT - if you're getting 10+ second hangs on Vista that you never had in XP, I had them too and they drove me mad - and they disappeared the minute I upgraded from 2GB to 4GB memory. I don't have any explanation for this colossal need for memory - it would imply quite an embarrassing new entry needs to be added to the system requirements page. But I never had these hangs on XP with 1GB memory on an older machine. So just FYI.
I must add that turning on Advanced (Ctrl+Alt+D) > Rendering > Run Multiple Treads did improve these symptoms and also resulted in a 10% increase in fps. Perhaps the viewer should automatically detect Core2Duos and enable this setting by default for those processors.
i have been running a (post voice) nicholaz viewer for months which does not have the problem, went back to the latest linden viewer, and i get the problem again. can someone ask nicholaz for cooperation on fixing this?
I can confirm that this is still happening on my system and I have a fully updated XP installation (XP, SP3, 4GB, P4 Duo Core 2.1GHz, nVidea 8800GTX/SLI 768MB GDDR3).
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. I have attached a more elaborate comment to VWR-559, as that is now classifed as a meta issue of this one, but I thought I'd flag it here so people who don't watch the meta issue would still know about it. Basically I'm adding two pieces of information:
(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 Happening to me as well. In both, Ubuntu 8.04 and Windows XP (both with latest available updates and drivers) and in both (again), latest RC and regular release. CPU usage turns to 100% for no obviouse reason, no matter which graphics settings and returns to normal again short after. Freezing / lagging while on 100%. Network and Server act fine (green) meanwhile.
CPU: AMD (Unknown model) (3013 MHz) edit: CPU is AMD Athlon 64 X2 6000+ Zai:
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) @Michelle2 Zenovka:
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. Curious thing, Rob Linden reported "out of order packet" in his report and Comcast has been (in)famous for this as a method of "punishing" peer-to-peer users and bittorrent users. They claim that "5% of users are using 50% of bandwidth",.. which is a logical fallacy since they do not state if those 5% are the same 5% each time or not. Also, ISPs in Texas (Time Warner, who originated that 5%/50% nonsense) and elsewhere are experimenting with OOP as well as Packet Spoofing (which I have witnessed - where do all those RST packets come from?). Methinks looking within the client for this problem may not be the best place to put the sole focus of our efforts and a parallel effort to beat the crap out of the client-to-server network needs to happen.
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. This has been announced fixed in the latest Release Candidate 11. I am currently using that to test whether this has been fixed. I have my draw distance up nice and high, in a sandbox, and am currently staring out to sea. From my testing so far, this seems to be fixed, but it'll take me more time to make sure.. I encourage other people here to test the new RC11 as well.
http://blog.secondlife.com/2008/06/25/now-available-optional-release-candidate-viewer-120-rc11-dazzle-we-hear-you/ 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. Definitely vastly improved all round, but today on the latest RC14, I've been getting chains of continuous 10-30 secs to indefinite freezes one after the other until I have to end up killing the viewer sometimes. Incidentally, the freezes seem more frequent when there's server issues, but I guess that's just coincidential.
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. I have resolved this bug as fixed in viewer 1.20. The internalID equivalent of this bug is considered fixed as part of the LLMotionController code cleanup (correlated with
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Regular viewer freezes since update to Voice viewer
)
the whole evening:
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.