trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: May 2013

Re: [trinity-devel] KDM resolution problem / crash in kcm displaymanager

From: Slávek Banko <slavek.banko@...>
Date: Sat, 11 May 2013 02:17:14 +0200
On Friday 10 of May 2013 18:37:46 Fran�ois Andriot wrote:
> Hello,
> in my current 3.5.13.1 installation, I still have trouble setting the
> correct screen resolution for TDM.
> When going into the "kcmshell displaymanager", I  always crash when
> saving settings, and they are not saved at all.
> (they are supposed to be in something like
> /opt/trinity/share/displayconfig/... )
>
> Using GDB I see it SEGV line 115 of the following file:
> http://git.trinitydesktop.org/cgit/tdelibs/tree/krandr/libkrandr.cc?id=v3.5
>.13.1
>
> I see that a patch to avoid crash was submitted and backported in SRU:
> http://git.trinitydesktop.org/cgit/tdelibs/tree/krandr/libkrandr.cc?h=origi
>n/v3.5.13-sru Basically, the "delete" is conditional. Good point.
>
> But I think the true problem is not to avoid the "delete" function, but
> to know why we go in there.
>
> Looking at this file, line 287:
> http://git.trinitydesktop.org/cgit/tdebase/tree/kdm/kfrontend/kgapp.cpp?h=o
>rigin/v3.5.13-sru I see that the "ICC Profile" parameter is set to "" (empty
> string).
>
> Back to the "KRandrSimpleAPI::getIccFileName" in tdelibs, I see that the
>
> profileName variable is checked 3 times:
> |84  if (profileName != NULL) {|
> |
> |91  if (profileName != NULL) {
> |
> |
> |111  if (profileName != "") {
> |
> |So, if profileName is set to ""|, the 2 first tests are positive, and the
> | third is negative.
>
> We create variable|||"t_config" but then delete variable "t_systemconfig".
> Then it (used to) crash.
>
> I think something must be clarified here: if the function is meant to
> receive "no profile" as paramater, we must choose if this is NULL or or an
> empty string.
>
> Or we can check both value if both must be valid, e.g:
> |||if ((profileName != NULL) && (profileName != "")) {|
> |
> |What do you think ?

Fran�ois, that's a good point.
I attach a patch with one possible solution.

Slavek
-- 

Attachments: