KDE 4.6.2 screensaver module crashes with fglrx 8.850

[Eric Griffith]

And the plot thickens lol. Turning off compositing allowed me to
access the screensaver module (from fglrx) and set a screensaver.
Rebooted to change something in windows, when I came back into KDE
just out of a random whim I loaded up screensaver again, with
compositing enabled, and it worked. If any of the KDE devs took a
notice to this thread and could give a bit from information or
suggestions other than testing out other versions of KDE (DL'ing some
live CD's now) it seems that Screensaver crashes with fglrx if there
isn't a screensaver set already, once it one is set though,
everything's fine. So is there a bool value being used for whether one
is or is not set? or an int that says which screensaver is set that
starts off as null?

Just taking shots in the dark since I know some C++ but I doubt enough
to effectively debug this.

On Mon, Jun 20, 2011 at 10:07 AM, Duncan <1i5t5.duncan at cox.net> wrote:
> Eric Griffith posted on Mon, 20 Jun 2011 03:47:42 -0400 as excerpted:
>
>> First post to the mailing list so work with me a bit on this haha.
>
> You did quite well for a first post, including a lot of useful info a lot
> of folks forget, like kde version, distro (version would have been nice,
> but only for folks running kubuntu so they know its significance, many
> will be running other distros), a good description of the problem... you
> even posted in plain text, not the HTML that many won't like. =:^)
>
>> After being a long time Gnome fan I decided to jump over to KDE as I
>> absolutely abhor the direction that Gnome-Shell and Unity are heading in
>> (yes im kubuntu).
>
> I doubt you'll find many to argue with that, here. =:^)  Of course, not
> /too/ long ago, there were (and still are to some extent) many saying kde
> was going wrong with where they were taking kde4, as well.  Just sayin'.
>
>> Everything was actually going fairly well, as I would
>> expect from an ubuntu install except for one small problem.
>> Every single time that I load the screensaver portion of KDE Control;
>> KDE Control crashes with a seg fault.
>
> kcontrol's so much more accurate and less generic than systemsettings,
> don't you think?  I'll never know what got into the kde folks, renaming
> it the impossibly generic (just TRY googling it!) systemsettings, when
> it's mostly user-specific kde settings, and even where it's global
> systemsettings, it's the kde method for setting it, so kcontrol works for
> both while systemsettings is simply inaccurate and impossibly generic.
>
> That's a pet peeve of mine.  Nice to see someone still using the kcontrol
> term. =:^)
>
>> Doesn't matter if I go into Kickoff and search "Screensaver' or if I go
>> into System Settings > Display > Screensaver, as soon as Screensaver
>> tries to load, it crashes. Backtrace follows; I know it mentions fglrx's
>> libGL, but I'm posting it here because I don't know if this is exposing
>> a bug in the way FGLRX renders KDE, or in the way that KDE requests an
>> OpenGL call.
>>
>>
>> Application: KDE Control Module (kcmshell4), signal: Segmentation fault
>>
>> [KCrash Handler]
>>
>> #7 0xb2aaaae8 in XF86DRIQueryExtension () from /usr/lib/fglrx/libGL.so.1
>>
>> #8 0xb5fc7ae6 in _XFreeReplyData (dpy=0xb75ff7ee, force=<value optimized
>> out>) at ../../src/xcb_io.c:498
>>
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> While I'm a gentoo user and thus reasonably technical, I'm not a coder
> and backtraces don't normally help me much.  However, if I'm reading this
> correctly, your crash (segfault) is due to a null-dereference, because
> the value it's trying to reference was optimized away.
>
> That's... interesting, to say the least!  Given I /am/ a gentoo user, I
> know a bit about C(XX)FLAGS and their affect on optimization, plus of
> course new gccs changing the rules and optimizing stuff that they didn't
> before, thus sometimes causing problems with existing sources built with
> the new compiler, until the sources are adjusted to take into account the
> new optimization rules.
>
> But presuming you're not building it yourself, somebody would seem to
> have screwed up, here.  I'm guessing that it's your distro, in the
> choices of optimizations they used, but can't say for sure since fglrx is
> partially pre-compiled and it might be from it.  (Yes, I know that's
> about what you said; I'm agreeing, with the additional note that
> whichever, that's an interesting backtrace as it's so blatantly a null-
> dereference.)
>
>> If anyone can help me out, I'd love it. I'm using the latest available
>> packages from the xorg-swat ppa, and the kubuntu-backports ppa
>
> Unfortunately, I can't be of much direct help, but here's some
> suggestions that might help get further information or be useful as
> workarounds.
>
> 1) Try turning off desktop effects/compositing.  That might or might not
> help, but if it does, you can at least get into screensavers to change it
> to something other than an opengl one, allowing you to at least have a
> screensaver and change basic settings.  And if it doesn't, you have one
> more data-point on your list of what does /not/ help.
>
> 2) I have a Radeon (hd4650) here, but by personal policy is that I don't
> run servantware, in the context of my sig, so I know next-to-nothing
> about fglrx's settings. (I did run the servantware nVidia driver for a
> year or so after switching to Linux, nearly a decade ago, so know a bit
> about how it worked at least back then, but know nothing at all about the
> ATI servantware driver, except that it's not even legal for me to run it
> since I can't agree to the EULA, etc, so they don't give me permission to
> run it and I'd be violating copyright to do so.)
>
> As such, I can't help you with specific settings, but you might try stuff
> like turning off pageflipping and other optimizations in the fglrx
> driver, to see if that helps.  Also consider trying kms vs ums (kernel vs
> user modeswitching, it might not be an option on the closed drivers),
> classic vs gallium driver, and exa vs xaa 2D accel.  Again, this isn't
> necessarily permanent, but it might allow you in at least long enough to
> switch to a working screensaver, and it gives you more working vs non-
> working datapoints.
>
> 3) Try the native freedomare xorg/kernel/mesa radeon driver.  If it
> works, you know the problem's in fglrx.  Otherwise, it's not.  Very good
> datapoint to add to the list either way.
>
> 4) Try different fglrx drivers, newer or older.
>
> 5) Try a window-manager other than kwin.  Compiz is quite popular on kde
> as well as Gnome.  Again, it doesn't have to be a permanent choice; just
> getting the data-point as to whether the problem is kwin specific is
> helpful.  You might wish to try a simpler 2D window manager as well, just
> to see if the OpenGL effects are throwing it off.
>
> 6) Try older kubuntus, possibly liveCD/liveUSB so you don't have to
> disturb your existing installation.  Presumably these will have older
> kde.  I'd suggest trying something with later kde 4.5 (4.5.4 at least, or
> 4.5.5), and a later 4.4 as well, to see if it's a new problem, since you
> just switched from gnome and thus don't know if the older versions worked
> or not.
>
> 7) Try other distros. Again live* will allow you to avoid messing with
> your current installation for the test.  This could help isolate whether
> it's a (k)ubuntu specific problem or not.
>
> FWIW, kubuntu has at least in the past had problems with kde that other
> distros didn't.  Whether that continues to be the case or not, I don't
> know, and of course, it's your choice what you run, but I'm just saying
> that while Ubuntu may well have been a good chose for those on Gnome,
> historically at least, kubuntu wasn't the best choice for kde users.  You
> may wish to take that into account if indeed you're serious about
> switching to kde for awhile.  OTOH, that's historic data and maybe
> kubuntu's better now.
>
> But regardless of what you choose to install, live* versions make it easy
> to check if a particular issue is appearing on other distros, thus
> narrowing it down to the distro, or verifying that it's not distro
> specific, as the case may be.
>
> 8) This one really should have gone earlier, but I forgot it until now.
> It may not apply in your case since your kde is apparently a new
> installation, but for people who have been running the same home for some
> time, setting up a new user and seeing if it works with it, thus, whether
> it's a user configuration problem, can be quite helpful.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
> ___________________________________________________
> This message is from the kde mailing list.
> Account management:  https://mail.kde.org/mailman/listinfo/kde.
> Archives: http://lists.kde.org/.
> More info: http://www.kde.org/faq.html.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.