Cool VL Viewer forum

Greetings.

Just wanted to report a crash that happens occasionally while using Cool VL Viewer 1.26.7 (2). The crash would occur randomly at various times on various sims. The viewer would stop rendering and would also stop responding to any keyboard input or mouse input. Only the last rendered picture would be displayed, along with the viewer's unresponsive GUI windows. I would then have to use the Task Manager to end the Cool VL Viewer process before starting Cool VL Viewer again to relog into Second Life.

The SLVoice plugin would continue to work despite the crash, though; I am still able to listen to Second Life Voice conversations like normal whenever this crash occurs. The Voice plugin would continue to work as normal until I use the Task Manager to end the Cool VL Viewer process, which would cause the SLVoice plugin's process to terminate by itself.

I noticed that the crash seems to occur whenever Cool VL Viewer is made the foreground application again, after other applications were brought to the foreground previously (either via ALT-TAB or via the buttons on the Windows taskbar). However, that factor might be a coincidence, since this crash has also occurred while Cool VL Viewer was being used as the foreground application without any form of foreground application switching.

Computer Info and Viewer Info:


Thank you.

The crash dump doesn't give any useful information, since the crash is just the result of the watchdog timer of the viewer kicking in and voluntarily aborting the process when it notices that the rendering stopped. The log doesn't show anything abnormal either...

As a first guess, I'd say it could be a graphics driver bug (the crash on window/desktop switching is something I saw happening, sometimes, with NVIDIA drivers under Linux, and were clearly drivers bugs (with a backtrace pointing into the driver code and a "NVRM: Xid" error code in the /var/log/messages log indicating a crash in the card BIOS): alas, under Windows, there's no such thing as proper, system level error logging, so it's much harder to diagnose such bugs...

Another possible reason for such graphics related crashes/freezes would be too high an overclock on the GPU (be aware that some graphics card makers overclock the GPUs by default in their cards to make them appear artificially faster than the competing makers' equivalent cards), or an overclock of the PCI bus (such an overclock is very dangerous for the system stability)...

You could try using a different version of the graphics driver (non-beta versions preferred, of course), including older ones (sometimes, older is stabler...), and of course, if anything is overclocked in your system, I'd recommend trying at stock speed for a while and see if it solves the issue...

I saw this kind of thing happening under Windows when plugging-in or unplugging a thumbdrive or any other external drive to the USB port. Rendering stops. Sometimes the viewer recovers from it, sometimes it doesn't. Don't know if this is the same thing that is happening here...

This is another issue, but it might also trigger the watchdog: when you plug a drive and your OS initializes it and links its partition(s) to its filesystem, it also locks all processes that attempt to access the said filesystem to avoid corruptions of internal data structures (inode pointers, file and drive descriptors, etc) and unlocks them only after the new drive is ready and fully initialized. Since not all OSes are created equals (and Windoze is by far the worst OS in this respect like in many others...), the result can be a simple freeze of the applications that were accessing files when you plugged the device, or a crash during their call to the OS filesystem layer.

If the crash you get is because of an excessively long freeze (which would trigger the viewer wtachdog), try increasing the MainloopTimeoutDefault debug setting value (it defaults to 20s).

Thanks for the tip about MainloopTimeoutDefault. I've increased it to 30 seconds for now.

About the issue: Windows may actually be able to handle this better than Linux. As Windows has not one big filesystem like Linux, but several drive letters, there should actually be no reason why the existing drives get locked temporarily just because another one is added. I think I'm gonna write a test-program about this to find out what actually happens to file-access while a thumbdrive gets added... Could be interesting...

Believe me, it doesn't !

Even if the Windows filesystem tree doesn't *appear* as a single tree like in UNICES, it nonetheless *must* get locked while new drives are added to it (it would be too long to explain why here, and it's not the object of this forum, but believe me, it's how it works (and fails) !).

Ok, I just did some testing for file-system performance during plugging-in/unplugging a thumbdrive on Windows7-64bit.

Long story short: If there is any locking, then it is only for a VERY tiny amount of time. Definitely way, WAY less than 1/10 of a second.

The program I wrote does a 5 second-long test. During that time it continously creates a file, writes to it, closes it, then deletes it again. Logs all the performance-data for intervals of 1/10 of a second into RAM. Does about 350 creates/writes/close/deletes for every 1/10 of a second. All logging-data is stored into RAM first and only displayed after the 5 seconds are over. I plug-in or unplug the thumbdrive during that 5 seconds.

Performance is the same during the entire test. No delay, error or slow performance at some point.

Conclusion: If there is any locking, then it is definitely shorter than 1/10 of a second, probably even less than 1ms.

Whatever causes the viewer to freeze after plugging-in a thumbdrive is not due to locking of the file-system. LL must have done something very weird somewhere in the code.

Still this is a VERY minor issue. I only wasted some time on it because I was simply curious.

(A little later)
I think the viewer-freeze is due to some joystick detection. See the attached logfile. The freeze happens around 10:38:09Z.

Is there a way to disable joystick support in the viewer? I've never used that. Does anyone???

This is irrelevant if you don't lock the file and flush after each write (and flush caches after each read).

I could add a setting to completely forbid any initialization attempt...

Thank you Henri! With this setting enabled in v1.26.7.4 adding/removing a thumbdrive no longer causes the viewer to stall.