Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2025-08-08 12:24:38



Reply to topic  [ 10 posts ] 
Crash on graphics change 
Author Message

Joined: 2010-09-30 17:54:18
Posts: 29
Reply with quote
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.
Attachment:
File comment: Log - switching to window mode
SecondLife.log [2.57 KiB]
Downloaded 232 times

Attachment:
File comment: Trace - after crash
stack_trace.log [2.3 KiB]
Downloaded 212 times

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:
Code:
*** glibc detected *** bin/snowglobe-do-not-run-directly: free(): invalid pointer: 0x09dc1000 ***
======= Backtrace: =========
/lib/libc.so.6[0xb729d564]
/lib/libc.so.6(cfree+0x90)[0xb72a1010]
/usr/lib/tls/libnvidia-tls.so.1[0xb6209a60]


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
Profile

Joined: 2009-03-17 18:42:51
Posts: 6028
Reply with quote
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:
Code:
# Work around for a crash bug when restarting OpenGL after a change in the
# graphic settings (anti-aliasing, VBO, FSAA, full screen mode, UI scale).
# When you enable this work around, you can change the settings without
# crashing, but you will have to restart the viewer after changing them
# because the display still gets corrupted.
export LL_OPENGL_RESTART_CRASH_BUG=x
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
Profile WWW

Joined: 2010-09-30 17:54:18
Posts: 29
Reply with quote
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
    Code:
    export LL_OPENGL_RESTART_CRASH_BUG=x

    then the graphics get completely corrupted now
    Attachment:
    File comment: UI with enabled opengl workaround
    workaround.png
    workaround.png [ 4.33 KiB | Viewed 3895 times ]

    If I had this in my secondlife wrapper script
    Code:
    #export LL_OPENGL_RESTART_CRASH_BUG=x

    then the graphics get slightly less corrupted now
    Attachment:
    File comment: UI with disabled opengl workaround
    noworkaround.png
    noworkaround.png [ 10.25 KiB | Viewed 3895 times ]
  • 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.
Attachment:
File comment: Trace - after crash
stack_trace.log [1.27 KiB]
Downloaded 213 times


Hopefully this helps.


2011-08-03 01:42:40
Profile

Joined: 2009-03-17 18:42:51
Posts: 6028
Reply with quote
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
Profile WWW

Joined: 2010-09-30 17:54:18
Posts: 29
Reply with quote
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:
Attachment:
File comment: trace with llerr
stack_trace.log [1.64 KiB]
Downloaded 220 times

Attachment:
File comment: log - with error message
SecondLife.log [3.51 KiB]
Downloaded 194 times


2011-08-03 11:36:20
Profile

Joined: 2010-09-30 17:54:18
Posts: 29
Reply with quote
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:
Attachment:
File comment: trace - just crashing
stack_trace02.log [2.64 KiB]
Downloaded 233 times

Attachment:
File comment: log - without very interesting entries
SecondLife02.log [3.83 KiB]
Downloaded 215 times


2011-08-03 11:39:11
Profile

Joined: 2010-09-30 17:54:18
Posts: 29
Reply with quote
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
Profile

Joined: 2009-03-17 18:42:51
Posts: 6028
Reply with quote
poochieD wrote:
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.

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
Profile WWW

Joined: 2010-09-30 17:54:18
Posts: 29
Reply with quote
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
Profile

Joined: 2009-03-17 18:42:51
Posts: 6028
Reply with quote
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
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.