[kde-linux] KDE-4.3.2 settings - Regional & Language

[Duncan]

Dr. Edgar Alwers posted on Wed, 16 Dec 2009 17:45:14 +0100 as excerpted:

> Hi Duncan,
> 
> On Tuesday 15 December 2009 02:05:38 Duncan wrote:
>> 
>> strace -eopen -f kcmshell4 language
>> 
> crash also, the last lines beeing:

> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/opt/kde-4.3.0/share/locale/en_US/entry.desktop", O_RDONLY|O_LARGEFILE) = 21
> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/opt/kde-4.3.0/share/locale/en_US/entry.desktop", O_RDONLY|O_LARGEFILE) = 21
> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/opt/kde-4.3.0/share/locale/l10n/de/entry.desktop", O_RDONLY| O_LARGEFILE) = 21

> and nothing more happens.

>> strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user
>> 
> similar behaviour, last lines:

> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21
> open("/home/kde4/.kde4/share/config/kdeglobals", O_RDONLY|O_LARGEFILE) = 21

>> strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user | grep -v
>> 'lock'
>> 
> triggers a crash-handler after
> 
> *** glibc detected *** kcmshell4: free(): invalid pointer: 0x09944558
> *** ======= Backtrace: =========

I'm not advanced enough to do anything much with a backtrace...

>> strace -eopen -f kcmshell4 langugage 2>&1 | grep /home/user | grep -v
>> 'lock\|ENOENT'
> 
> This and all further commands did not work more at all. Activity frozen,
> string-c needed to get out.

These buffer the output, due to the second grep, not dumping it until
after the run completes.  If it's locking up and you have to ^C it,
you'd not see the output, since the ^C would abort the entire pipe.

What you could do instead would be to take the output of the working
strace command and redirect it to a file, then grep the file, like this:

strace -eopen -f kcmshell4 language 2>strace.out

grep /home/user strace.out | grep -v 'lock\|ENOENT'

... and go from there.  However, this post /may/ have provided what
we need.  See below.

> 
> HOWEVER:
> looking at all the lines containing
> open("/home/kde4/.kde4/share/config/kdeglobals" I took the risk of
> comment out "kdeglobals". After a restart of kde-4, I got a slightly
> changed desktop, but also the desired currency settings in "kmymoney".
> It solved my primary problem, but the "country/Region & Language" button
> of the KDE-Control module still crashes when intending to activate it.
> May be an installation problem in my self compiled kde-4.
> 
> Anyway, thank you again very much for your very interesting analysis,
> Duncan. I learned a lot.

They say the best way to learn something is to (try to) teach it;
it teaches the teacher too! =:^)  I've invariably found that to be
the case, as others always have questions, or in this case, results
of tests, that force the "teacher" to reexamine his own beliefs and
methods.

The most immediate example above is the buffered output from grep.
I knew that, and would have acted accordingly when I saw no output
and had to ^C, but didn't know it /well/ enough to foresee the
in hindsight obvious problem trying to troubleshoot a crasher, and
explain the fix, using a temporary output file.  So I've just had
that bit reinforced to me as well -- I (re)learned something myself.
=:^)

Back to the problem, tho.  It could be that I was wrong in the
assumption (for simplicity sake, because it's likely to be right)
that the issue was with the user config, not system config.  I did
/sort/ of cover that possibility at the bottom of my post, but I
should have put the test near the top, not the bottom.

You said 'comment out "kdeglobals"'.  I understand English isn't
your first language, but that phrase confuses me a bit, in just the
area we're headed, so we need to be sure we both understand each
other.  I /assume/ you mean "moved/renamed the file, so kde would
recreate it from scratch".  The more normal usage of "comment out"
would be /inside/ a file, to "comment out" a line or several by
preceding or surrounding them with comment sequence(s) (typically
a leading # in config files).  I'm unaccustomed to seeing "comment
out" in reference to a file itself, so am left confused as to
whether you /actually/ meant move/rename, or if you really did
"comment out" that file in some other config file.  Or, perhaps,
you "commented out" every single entry in the entire kdeglobals
file, tho due to its typical size, I wouldn't consider that practical
and thus discount that possibility.  Similarly, perhaps you
"commented out" the entry in the source code and recompiled
/something/ (I'd suspect not all of kde!), but that doesn't
make a lot of sense either, so I'm discounting that possibility
as well.

Anyway, on the assumption that you mean that you moved/renamed the
kdeglobals file so kde would recreate one from scratch...

That the language kcm is still crashing after that indicates that
it's either one of the other user files (not so likely), or that
the problem is the system config, not the user config.  The most
direct way to test that would be to create a brand new user, without
a user config in the homedir at all, and try it from there.
Alternatively, as root, rename your entire user homedir and create
a new, empty one, and try that.  The effect is the same either way.
Login to kde with the empty config, and see if you can run
kcmshell4 language from there.

At this point, I'm guessing that it will crash, even with a fresh
no-existing-config user.  Obviously, that indicates the problem is
NOT the user config, but either the system config, or just possibly,
a bad self-compile as you mentioned.

So we look at the system config...  A couple entries from that first
trace above, before we eliminated the system files, caught my eye:

/opt/kde-4.3.0/share/locale/en_US/entry.desktop [...] = 21

/opt/kde-4.3.0/share/locale/l10n/de/entry.desktop [...] = 21


BTW, not all the below is relevant to this particular problem, but
it's interesting, none-the-less, and may help you in troubleshooting
other problems down the line... or help others that are reading this,
or will google it up, later...

That the same file descriptor ((aka fd, the 21) was being given
indicates that the app was rapidly opening and closing various files,
grabbing info out of them as it did so.  If it was holding them open,
the fd would have been increasing.  (FWIW, the first three fds, 0-2,
are reserved for STDIN, STDOUT, and STDERR, so we know the app was
holding 18 additional files open at this point, 3-20.)

It can also be noted from the file-open flags (which I ellipsed,
above), that the files were being opened O_RDONLY, read-only.
That's just good programming practice.  Open them read-only now,
since that's all we're doing.  If the user changes the config,
the user files (not system) can be opened in write mode to write
out the new config.  O_LARGEFILE is also specified, but of little
interest to us.

Now that en_US/entry.desktop file was opened at least twice, and
closed without issue -- we weren't logging the closes, but as
explained above, it MUST have been closed, because the same fd
was used for the next file.

But that l10n/de/entry.desktop file... that's another story!
The file opened successfully as we got a non-zero fd, but the
app crashed immediately thereafter.

What you /could/ do at this point would be to broaden your strace
a bit, letting thru more than just file-opens.  In particular, you
could try -efile instead of -eopen.  Of interest if you did so
would be other operations on the file, using its fd of 21.
Typically, you'd see reads, returning information (a bit of
each data string would be included in the strace output), and
seeks, to various locations within the file, plus file closes.
You'd also see a lot of stat calls, which are normally used to
see if a file exists without opening it, get its permissions
and filesize, etc.  (Filesize can be of quite some interest if
the entire file is read into memory, for instance, since a
memory buffer of appropriate size would need to be prepared.
But often, only parts of the file are read in, using fseeks
to reach the portion of the file of interest.)  Of particular
interest in our case would be whether that file got closed
before the crash or not, and whether it did anything else with
the other 18 open files that might cause the crash after it
opened that file.

That would be /one/ way to go.  But perhaps more simply and
directly, since we have the name and path of the file of interest,
just open it in a text editor, comparing its contents to that
of the en_US file, and see if there's anything strange like
a run of obvious binary gibberish in what SHOULD be a text-only
file.  If there is, you found your culprit!

If the contents of the file /looks/ normal, you can always try
renaming it, and see if that does away with the crash.  Now
you'll probably lose any kde de/German l10n (localization)
temporarily in the process, but if it does away with the crash,
again, we have our culprit!

FWIW, that file (installed here locally as
/usr/share/locale/l10n/de/entry.desktop) is part of the
kdebase-data package here on Gentoo.  Gentooers compile from
source, but using Gentoo package scripts called ebuilds.  Since
kde sources come in several large tarballs, Gentoo splits most of
them down into individual packages, setup with dependencies so that
only the ones necessary for your chosen "leaf" packages get
installed, not the entire tarball's worth.  kdebase-data is obviously
from the kdebase tarball, which is what I'd expect you'd have to
recompile, if it gets to that.

But what I'd do first is compare the l10n/de/entry.desktop files
from your two installs, and copy over the file from the good one
to replace the bad one, if they are different.  Alternatively,
I could probably post mine somewhere, but as you have two installs
there to work with and one is working, that's going to be easier.

Of course, if the files on the working and non-working installs are
exact duplicates, then we're back to looking for something else
again...

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