Bloggy

If you’re a KDE developer using a recent version of glibc (since 2.10), you may have come across strange crashes complaining about memory corruption when running development versions of KDE (especially Okular, KTorrent, KNotify, and other KDE applications using threading).

This had been noticed by quite a few people (and was being tracked by KDE under bug 196207). Apparently OpenSUSE had noticed this as well and had submitted a patch to the glibc maintainers this past June, in sourceware bug 10282. I am happy to be able to say that the patch works for me™. So if you’re been having this issue, see about getting your distribution to update their glibc with this patch (or a better one, I don’t care ;)

Posted by mpyne under Computing Troubles & KDE & Useful Tricks | 1 Comment »

As usual, no (coding) progress happens for me unless something else is causing me problems on my system. In this case, I had the opportunity to need to use my library dependency viewer.

Qt is nice enough to link to KIO when run under a KDE desktop, so even though ELF Library Viewer only links to Qt right now, I still get the nice KDE file open dialog. This is 99% of the time a positive feature. But for some reason the dialog was crashing and just having a horrible time handling large directories (like, say, /usr/bin). Worse yet, I couldn’t simply type /usr/bin/foo and click OK, since that isn’t working either. Hmm.

I decided the easiest thing to do would be to add support for opening files passed to the command line of my application (and I was right). Since I was working on it anyways I also ported the build system to CMake (from QMake), and so now it’s possible to install it/make packages/etc.

I’ve placed the updated version on my software page in case anyone’s interested. Obligatory screenshot is the same as two years ago:

Now it’s back to reading research papers all day. :-/

Posted by mpyne under Computing Troubles & KDE & Programming | 2 Comments »

From IRC, a quote:

Son, we live in a world that has bugs, and those bugs have to be found by men with debuggers. Who’s gonna do it? You? You, OSS fan boy? I have a greater responsibility than you could possibly fathom…. You have the luxury of not knowing what I know. That the KDE 4.0 release, while tragic, probably saved developer resources. And that my existence, while grotesque and incomprehensible to you, saves developer resources. You don’t want the truth because deep down in places you don’t talk about at parties, you want me on that bug, you need me on that bug.

And in other news, I’m officially on shore duty, at my next duty station. I got to “help” the nice Comcast guy with hooking up cable Internet with linux, but other than that things went smoothly. (Protip:Have a DNS nameserver not part of Comcast memorized before hooking up the Internet. If you’re unlucky you’ll get to a point where your Internet works but DNS does not.)

Posted by mpyne under Computing Troubles & Funny & KDE & Useful Tricks | 2 Comments »

So after my latest X.org upgrade I forgot to recompile the xf86-input-evdev module as well. So of course when I ran startx again, my shiny KDE desktop came straight up… and I couldn’t move the mouse or use the keyboard. Drat.

Now I’ve been much more careful to cleanly shutdown KDE when possible ever since I started losing rc files with my previous filesystem. And besides which, I couldn’t use Ctrl-Alt-Backspace even if I wanted. So what I did instead was login with my laptop to try and shutdown KDE.

Of course, there’s still the tricky issue of how to cleanly shutdown your running session from a completely different shell. Luckily ksmserver (the process responsible for performing the shutdown) has a DBus interface:

kde-svn@midna ~ $ qdbus org.kde.ksmserver /KSMServer
method bool org.kde.KSMServerInterface.canShutdown()
method QString org.kde.KSMServerInterface.currentSession()
method void org.kde.KSMServerInterface.logout(int, int, int)
method void org.kde.KSMServerInterface.resumeStartup(QString)
snip

Of course, that’s what I get when I run if from my current KDE session. I was worried that in my ssh shell there would be problems with accessing the D-Bus session. So imagine my surprise when I was wrong, the command worked just fine even with no environment variable set. Huh.

Although it saved me from what I was going to do (look through /proc/pid/environ for a process that I knew was in the DBus session), it was still unexpected to me. Turns out that DBus will, if the environment variable is unset, try to “autolaunch” the session bus. This entails looking in the X session and in ~/.dbus/session-bus/ to look for the information on the DBus session, and if not able to locate the session, to simply launch another DBus session. In my case the information was available in ~/.dbus/session-bus/.

So I’m impressed, I was expecting it to be a giant pain in the ass and it was actually ridiculously simple.

Btw, the conclusion to the tale was: qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout 0 0 0. The three parameters were annoying for me to lookup so here it is:

The real signature: KSMServerInterface::logout( KWorkSpace::ShutdownConfirm, KWorkSpace::ShutdownType, KWorkSpace::ShutdownMode ). The parameters are essentially the same as in KWorkSpace::canShutdown() (link edited to work 2012-05-06), and the values are defined on that API page as well. One thing to note is that the final 0 (shutdown mode) is actually useless since we’re not requesting that a shutdown happen, only a logout. If we were requesting a shutdown, the shutdown mode is what selects whether to force a shutdown/reboot even if other people were also logged in, for instance.

Kind of as an aside, I’ve taken the liberty of updating my GPG keys due to the relative insecurity and low strength of the 1024-bit DSA key I had before. It should have a fingerprint of 5406 ECE8 3665 DA9D 201D 3572 0BAF 0C9C 7B6A E9F2, and is available here. Maybe someday I’ll even be able to attend a keysigning event to get it signed by someone else. :-/

Posted by mpyne under Computing Troubles & KDE | 7 Comments »

If you’ve been using kdesvn-build to build qt-copy, I recommend updating to the Subversion /trunk version, or using the 1.9.1 release. This is to adapt to a recent change to the qt-copy configure script, which causes an infinite loop (with subsequent disk fillup thanks to output logging). 1.9.1 will not work with older versions of qt-copy however.

For those who are interested, the change is to add a method for accepting a license without user prompting, which means that the previous method kdesvn-build employed (essentially running sed on the configure script) is now unnecessary (and harmful :-/).

In other KDE news, I ran across an issue with KWin closing on me after I closed out of all applications, starting from the other day. I’ve committed a fix to trunk, but I’m still not sure why it’s started exactly. But if you’re running into issues with KWin closing on you when you close all windows make sure to update kdebase.

Posted by mpyne under Computing Troubles & KDE & kdesvn-build | No Comments »

So the other day I had suffered probably the third dataloss in a year due to the XFS filesystem in use on my desktop + power loss.

Update: I just realized that I failed to mention that the dataloss is my fault, not XFS’s. Had I done more diligence in my research when I set it up in the first place I would have been aware of that particular shortcoming (shared with ext4 in its 2.6.29 and earlier configuration) where metadata updating before data, merged with powerloss could result in zero-length files. The files I lost were always ones being written to at the time, never just “random” files. Anyways…

I had already setup fairly well I thought, given that I was using RAID 1 (i.e. two redundant hard drives to hold one hard drive of data) and had UPS protection on the computer anyways.

The failures in my setup were notable though:

1. My backup strategy depended on me having enough time to actually hook up the external drive, run the backup, unhook it, etc. Scripting it so that it would take less time still required too much time to initially setup. Therefore my backups were fairly out of date. Compounding this, when I finally did setup the external and try to perform a backup, I found to my displeasure that it was ntfs formatted and therefore I couldn’t write to it. (I had the read/write ntfs-3g driver available but had forgotten about it by then, and didn’t have time to troubleshoot further).
2. UPS only works when your 2 year old son doesn’t go hard resetting the power on you.
3. UPS + disabling the front power switch only saves you until your next kernel panic induced by bleeding-edge video drivers (the fact that they were open source didn’t save me here ;)
4. The RAID worked — both hard drives were in the same inconsistent state, with the same lost files after the fsck… :(

The corrective action for all of this is complete however. Last night I used ntfsresize on the external drive (since it had data I wanted to retain) and used the free space to make a new ext3 partition for backups. From there I booted up a Gentoo LiveCD and copied all of the hard drive’s data to the external drive. I then reformatted the hard drives with ext4 (with appropriate mount options to avoid having it cause the same issues I have now with xfs) and copied all the data back.

There were some hiccups relating to me using manual mdadm commands to bring the hard drives online from the LiveCD. I apparently changed some of the md device names on the hard drives in the process which required some more manual mdadm –assemble action to fix. But everything is working so far, although I’m sure there’s a few packages that need to be reinstalled to account for the dataloss over time.

Luckily the major reason for my lack of free time looks like it will be rectified within the next week, more on that later.

Posted by mpyne under Computing Troubles & Personal | 14 Comments »

I remembered reading the discussion on kde-buildsystem about CMake 2.6′s CMAKE_PREFIX_PATH environment variable. I just forgot to add it to kdesvn-build.

Today it finally caught up with me: A build failure I was having ended up being due to not having CMAKE_PREFIX_PATH defined. Although adding it to the environment manually certainly works, it’s something that should have been in kdesvn-build. Well, it is now, at least in the /trunk version of kdesvn-build. It will also be in the next release of kdesvn-build.

My recommended workaround until then is simply to manually export CMAKE_PREFIX_PATH=/path/to/kde/install/prefix before running kdesvn-build (easiest would be to add to your .bashrc). Otherwise if you have a system KDE 4 (or the dependencies, like akonadi, strigi, etc.) then there is a good chance CMake will prefer the system installation to your kdesvn-build install and you’ll have build problems for modules expecting the trunk version of various dependencies.

Posted by mpyne under Computing Troubles & KDE & kdesvn-build | 4 Comments »

As most of you may have seen by now, foobar had made a post 10 days ago called “How to write a Linux virus in 5 easy steps.” That blog post was later covered on Slashdot and LWN, and describes the lack of security around .desktop launcher files. These .desktop files do lots of things, but one of their most prominent uses is in program launching.

Why are they needed? Well, they give a lot of extra metadata to executable programs, such as the icon to show, the friendly name, i18n translations, program working directory, whether a terminal-viewer should be launched in association, etc. Ever since their introduction, a .desktop file has been able to complete launching its associated program without being executable (that is, without have the +x bit set on the file for POSIX systems).

foobar makes a good point that in such a situation .desktop files are hardly any different than .vbs files in their effect if they were to be transported over email, and even if a .desktop file extension is not used, if the file “looks like” a .desktop file it will be handled as such. (For instance, on my KDE trunk desktop a .desktop file will be found out with a different extension or no extension, unless the fake extension is a known mimetype (like .jpg -> image/jpeg))

So this past week after some prompting by John Tapsell reminding us that we can’t drop the ball again I’ve been working on making .desktop files more secure. The issue is that we can’t simply require +x and see what happens, as even the installed menu icons in Kickoff are .desktop files, not to mention shortcuts on the Desktop and in the panel.

The alternative we hit upon in kde-core-devel was to allow .desktop file execution in the following cases:

• If the .desktop file were owned by root (i.e. part of a standard system installation)
• If the .desktop file was installed as part of the desktop environment (that is, it is from a known location for services, applications, and XDG-compliant applications. These correspond to the “services”, “apps”, and “xdgdata-apps” parameters to kde4-config --install). This allows for KDE installations to $HOME for instance.
• Finally, having the file be executable by the user always allows the launcher to run.

Unfortunately this still leaves the problem of what to do with launchers on the desktop or in the panel. Going forward we will need to make such .desktop files executable when they’re created but users who are upgrading would all of a sudden lose their custom launchers if that was all we did.

So in addition to the lockdown code I’ve been working on a reliable means of giving the user the option of automatically “fixing” the .desktop file and continuing on with execution. Doing this would make the file executable, and add an appropriate #! header if one wasn’t already present. (The interpreter used for .desktop files is /usr/bin/env xdg-open).

This is an example of a dialog that would pop up for such a file (“mileage tracker.desktop”):

The text isn’t set in stone yet (i.e. please suggest something better ;), I’m trying to make it descriptive enough to be useful without making the text so long as to simply lull the user into clicking “continue”.

One thing I haven’t done yet is to touch base with the XDG mailing lists to see if this requires revision to the specification (that way we don’t unintentionally break GNOME/Xfce/etc. apps on KDE, and don’t have ours broken). Mostly this was a matter of time — I already have little of it so it hasn’t quite percolated up in my priority list yet.

You can see my latest patches on the kde-core-devel mailing list. If you see any issues please don’t hesitate to email me or otherwise let me know sooner rather than later so we can either get them fixed or verify that it’s not an issue.

Posted by mpyne under Computing Troubles & KDE & Programming | 21 Comments »

I’m sure there’s already a million “Happy New Year” type posts up but I figured I’d throw in my two cents as well (since I’m actually here for this New Year’s Day).

While I’m at it I’ll pass along some things I managed to accomplish over the past week:

• Have some troubleshooting that you need to do that requires you to have a small partition? (In my case, troubleshooting for bug 118594). You don’t need to re-format your hard drive. Instead (at least on Linux) just create a partition on a file:
  1. Create a small-ish file (for instance, using dd if=/dev/zero of=file-name-here bs=1M count=size-in-megabytes).
  2. From there, you need to create a filesystem on it. I used plain ext2. If you’re not running as root you may need to manually run /sbin/mke2fs file-name-here. (since /sbin is normally only in the PATH for root). mke2fs should complain about the file not being a special block device but you can tell it to proceed. Please note that mke2fs is a horribly horribly destructive thing to do on a live filesystem. Make sure to take the extra second to get the filename right, and don’t run mke2fs as root.
  3. From there you can mount the file using the loop device. I had to do the following: mkdir test-dir # Create directory to mount filesystem to
sudo mount -o loop ./file-name-here ./test-dir/.
     On my system root permission is required to run mount even for a single-user mount like this, it may be different on yours.
  4. Now use your new filesystem normally. Any changes that you make to the test-dir/ folder actually affect the file you created for that purpose. This is handy for testing out-of-disk-space problems in your app.
• If you use Gentoo you will want to start shifting over to split ebuilds if you haven’t already. Their KDE-style modules were stopped (for the most part) at KDE 3.5.9, which was fine with me until every emerge world I tried to run started complaining about blocked packages at the various kdelibs requirements started to get inconsistent. I’ve decided to take this opportunity to simply get rid of the majority of the system KDE 3 and upgrade to KDE 4.1.3 instead. So far my wife hasn’t complained about it at all (and she really likes KSudoku as well) so as soon as I’m convinced I haven’t forgotten to install a KDE 4 program I’ll need I’m going to uninstall KDE 3 with the exception of the libraries and a few apps.
• World of Goo is definitely worthy of play. A Linux version is in beta but the Windows demo ran fine for me in WINE. Well, it crashed WINE on shutdown before the video mode had been restored but I suppose that’s good enough nowadays. :)

Posted by mpyne under Computing Troubles & KDE & Personal & Useful Tricks | 1 Comment »

So in the course of developing the next code feature I plan to add to kdesvn-build (nothing major, just adding a persistent data store) I came across what I consider an oddity:

Imagine that we had a hash table, mapping module names to the count of consecutive build failures. Now let’s say we want to pare down this hash table to a list of modules with more than a given number of consecutive build failures (3 as an example). This could be done using Perl’s grep function to strip out list entries that don’t match a given criteria (in this case, hash keys whose associated failure count is not >3).

Now I didn’t feel like making this test inline (although it would not have changed the end result) so let’s assume that I put my comparison function separately in an anonymous subroutine:

Now if we use this code to search for hash table entries with an appropriate number of failures, you’ll find that it instead returns all entries in the list that are present in the %moduleFailures hash table at all!

So what happened? The key is in the and operator. Most Perl programmers know that Perl has two sets of logical operators. C-style (&& || !) and English (and or not). These are described in the perlop Perldoc page. Basically the reason for the two different sets is syntactical convenience (for example being able to do print FILE "text" or die without having to put parentheses around your expression.

The way this bites you here is that Perl evaluates return (foo) and (bar); as (return (foo)) and (bar);. I’m not sure how the parser allows for using the return value of the return statement without so much as a warning but there we have it.

The solution, of course, is either to fully parenthesize your expression, or to use && instead of and in this case.

Posted by mpyne under Computing Troubles & KDE & Programming | 2 Comments »