Author |
Message |
poochieD
Joined: 2010-09-30 17:54:18 Posts: 29
|
Since Cool VL Viewer 1.26.0.12 is now considered stable I wanted to drop the old 1.25.0.40 and switch, but ran into the following problem: When I do certain graphics settings changes, in this case switching from fullscreen to window, the viewer just crashes. See the attached logs for info. Just a guess, is there a memory allocation issue with the new tcmalloc? Whatever it is, I hope there is a solution as it's not good to be stuck with an unmaintained old viewer version. Cool VL Viewer 1.25.0.40 doesn't crash and works fine in the same situation. Something I tried out: I'm using NVIDIA proprietary linux driver 275.21. When downgrading to a very old version 180.29 the viewer doesn't even start up and prints out to the console: System: Cool VL Viewer 1.26.0.12 Linux 32bit OpenGL 3.3.0 NVIDIA 275.21 glibc 2.7
|
2011-08-02 21:46:26 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6028
|
Changing the resolution and/or anti-aliasing and/or anisotropic filtering while the viewer is running never properly worked under Linux. I implemented a work-around in the Cool VL Viewer: if you disabled this work around, it will lead to crashes most of the time (but may depend on your graphic driver version). The workaround is toggled via an environment variable, in the "snowglobe" wrapper script. It is normally on by default: I you commented out the export, then the work around is off, and getting crashes is "normal"... Future versions of v1.26 might bring some improvement (via the backport of the GL font system from v2 viewers, since one reason for the crashes is that some font pointers are spuriously dereferenced on OpenGL restarts), but it is not currently a priority for me (Mesh must come first). Make sure first you got the workaround active then, if you still encounter crashes, please give precise repro steps since I can't reproduce the bug here.
|
2011-08-02 23:11:15 |
|
 |
poochieD
Joined: 2010-09-30 17:54:18 Posts: 29
|

Thanks for your reply. I'm aware of the opengl workaround environment variable. I used to keep the workaround disabled for the 1.25.0 viewers since I've never encountered crashes. To see if the bug is related to this setting, I did some test runs with the opengl workaround enabled and disabled as you suggested. The result is that I experience crashes regardless of the setting of the mentioned workaround. Next I played around with the graphics settings and surprisingly noticed that it seems I could NOT trigger the crash by changing and applying antialiasing, anisotropic filtering and resolution settings. The only way to trigger the crash reproducably so far is by toggling window/fullscreen via ALT+Enter shortcut. Next I tried to find a clean way to reproduce the crash bug on affected systems. This is what worked for me reliably: - Fresh install Cool VL Viewer 1.26.0.12
- Delete everything in the profile folder .secondlife
- Start the viewer, accept TOS, and login
- Hit ALT+Enter for fullscreen mode
If I had this in my secondlife wrapper script
then the graphics get completely corrupted now
If I had this in my secondlife wrapper script
then the graphics get slightly less corrupted now
- Hit ALT+Enter for window mode
I had to repeat this step unpredictable times, but never more than twice. Sometimes the viewer might not seem to do anything at all, sometimes the window mode might change to an all black window etc. On the last ALT+Enter the viewer crashes.
Here's another stack trace that I produced during my many tries. Hopefully this helps.
|
2011-08-03 01:42:40 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6028
|
The graphic corruption is normal: it's the result of the work around, the latter preventing the crash at this cost (like explained in the comment before the "export" line in the wrapper script).
You were incredibly lucky that you could disable it and not crash with former versions (probably a favourable combination of graphic driver and fonts)...
Thanks for the crash log (it shows that the code path reaches a llerrs, meaning the code detected something going wrong), alas you didn't provide the corresponding SecondLife.log which contains the reason (and location) of this llerrs... Please, do provide it.
|
2011-08-03 07:50:29 |
|
 |
poochieD
Joined: 2010-09-30 17:54:18 Posts: 29
|
Unfortunately I can't provide the SecondLife.log for the specific trace above because I backuped a wrong file. Instead I did a dozend of new tries to produce something similar with an ERROR log entry pointing to llviewertexture.cpp:
|
2011-08-03 11:36:20 |
|
 |
poochieD
Joined: 2010-09-30 17:54:18 Posts: 29
|
Most of the time there's no ERROR entry in the SecondLife.log and the viewer just crashes with traces/logs similar these or sometimes even incomplete traces and logs:
|
2011-08-03 11:39:11 |
|
 |
poochieD
Joined: 2010-09-30 17:54:18 Posts: 29
|
The changelog for Cool VL Viewer release 1.26.0.13 indicates some changes in graphics hardware settings, so I've checked if the viewer behaviour has changed regarding this bug report. These are my observations: - The viewer still crashes after toggling window/fullscreen like described above.
- Anisotropic Filtering and OpenGL Vertex Buffer Objects seem to apply immediately with no UI corruptions and no crashes.
- Antialiasing applies only after clicking "OK" button and causes UI corruptions but no crashes on itself.
- Doing the same after window/fullscreen has been toggled at least once, it can indeed cause a crash.
|
2011-08-06 15:54:01 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6028
|
Which corresponds to the behaviour of v1.25 and former versions (all versions of all viewers after v1.19 have been plagued with OpenGL restarts issues under Linux). Like I already explained above, there will be no improvement before I get Mesh implemented.
|
2011-08-06 21:05:03 |
|
 |
poochieD
Joined: 2010-09-30 17:54:18 Posts: 29
|

Just to make sure that nobody get's the wrong idea and running the risk of repeating myself.
It's understood that some people ever since experienced UI corruptions and crashes (the latter only until you created the openGL workaround). It's not Cool VL Viewer's fault because it's inherited from the official viewer after v1.19, and people got used to it so good that it's not too critical to find a fix.
But for me, and maybe I might not be the only one, this is a true regression. Those who were "lucky" and experienced NO UI corruptions and NO crashes in Cool VL Viewer v1.25 are now presented with a viewer v1.26 that corrupts UI AND crashes.
Unfortunately I couldn't find a repository of v1.26.0.x versions so I could tell you exactly which version's diff introduced the regression for me.
Of course I'm not the one to set priorities for Cool VL Viewer (bugs, features, mesh,...) but I hope you don't let regular users like me be stuck with crashing or deprecated versions for too long. In the meantime I'll just keep you up to date with any new observations and helpful info that I can come up with.
|
2011-08-07 12:32:54 |
|
 |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 6028
|
I'll be repeating myself a last time then: you were simply incredibly lucky that one version of v1.25 did not crash on you: the crash is due to memory corruption, and it's likely that that particular version simply corrupted its own memory (instead of the system memory), thus not triggering an immediate crash (but some data still gets corrupted and you could crash later on because of this). This is NOT the result of a difference in the code dealing with hardware graphics settings, but rather a result of how the linker arranged the various functions in the code at compile time. Compiling the very same code with another compiler version could perfectly result in a crashing version.
And again, this issue will be dealt with later, since for now my #1 priority is Mesh support.
|
2011-08-07 16:16:02 |
|
|