Latest KDevelop plugin improvements

Hi there!
Let’s review what I’ve done to KDevelop’s kdev-cppcheck and kdev-valgrind plugins lately.

JSONized kdev-cppcheck and kdev-valgrind

This is fairly straightfoward: These plugins were still using the old .desktop plugin manifest files. Now they are using the embedded JSON manifests. This isn’t something user visible, but it’s needed as the old .desktop method is now deprecated.

Added the number of calls to the callgrind output of kdev-valgrind

Until now the callgrind output has only shown the IR and Inclusive IR fields. Now is shows the number of calls as well. Take a look at the pictures!


Reorganized the output of memcheck in kdev-valgrind

Until now kdev-valgrind’s memcheck output unfortunately didn’t show enough of the callstacks to be really useful. You couldn’t see where the problem exactly occured, or where it was stemming from! Now it shows the full backtrace + the auxilliary trace as well, so you can see what actually causes the problems. See the pictures!



Graphisoft meetup

Today I participated in a meetup with Graphisoft‘s technical lead at LOffice Budapest.

All in all it wasn’t that interesting. Mostly it was about their hiring practises and the personal interview experiences of the speaker. Their interview practises aren’t that different from other top tech companies, however they don’t have n+1 rounds of interviews, only one 1-1.5 hours long one, with 30 minutes of technical interview. Like other top tech companies they don’t look for coders, but creative, smart software engineers with a software architectural vein. According to the speaker in the technical part they give you a 1 page long code piece, which you have to read, understand, explain, and criticise. If you know what you are talking about, and they get the impression that you could work together, they will hire you.

Some interesting numbers:
Archicad has 17 MILLION lines of ( mostly ) C++ code.
In the past years they got about 2000 CVs, they interviewed 500 people, and hired 50.

Also on Windows they use Visual Studio, on OS X they use XCode with LLVM and LLDB. For version control they use Perforce.

Lastly,  the audience got some PR gifts:


Java applet woes with https

Last year I created a simple Asterisk ( a VOIP server software ) extension monitor java applet for a client. It worked fine, but there was a problem when trying to load it from a https URL. It kept throwing exceptions.
Since it doesn’t send or receive any sensitive information, and it works inside an office in a closed system, it wasn’t a problem, just had to make sure the applet is loaded from http.

However today I had to deal with the applet again, and I wanted to solve this problem this time. On Windows 8 ( Windows 7, and Linux with OpenJDK IcedTea plugin doesn’t seem to be affected this time ) it kept throwing me these exceptions:

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at$ Source)
at$ Source)
at Method)
at Source)
at Source)
at Source)
at Source)
at Source)
at Source)
at$Initializer$ Source)
at Method)
at$Initializer.<clinit>(Unknown Source)
at Source)
at Source)
at<init>(Unknown Source)
at<init>(Unknown Source)
at Source)
at Source)
at$JarLoader.getJarFile(Unknown Source)
at$JarLoader.access$800(Unknown Source)
at$JarLoader$ Source)
at Method)
at$JarLoader.ensureOpen(Unknown Source)
at$JarLoader.<init>(Unknown Source)
at$ Source)
at Method)
at Source)
at Source)
at Source)
at sun.plugin2.applet.Plugin2ClassLoader$ Source)
at sun.plugin2.applet.Plugin2ClassLoader$ Source)
at Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$ Source)
at Source)

Caused by: access denied (“java.lang.RuntimePermission” “loadLibrary.sunec”)
at Source)
at Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at Method)

While I was googling around, I found this stackexchange discussion, that is about basically the same exception. So I tried the offered solution, and guess what? It worked.
So apparently the JRE doesn’t have permission to access it’s own libraries while running an applet from a https URL.

So to reiterate the solution: If for whatever reason you encounter this exception, try adding the following to your java.policy file in the JRE’s lib/security directory:

grant codeBase “file:${{java.ext.dirs}}/*” {

Interestingly enough, on Windows 7 the policy file already has this entry! Which is plain weird.

kdev-valgrind at work

I’m happy to report that it works! I didn’t have to actually change anything anymore, just set it up and run it using an example program.

Here are some screenshots, showing the KDevelop integrated memcheck, massif and callgrind tools at work:




KDevelop plugins, debug lessons learned

While working on kdev-valgrind, I learned some debug lessons about them, and kinda made up a smaller checklist for problems I’ve encountered.

Problem: plugin doesn’t load

  • Is the plugin installed to the right directory?
  • Is the plugin path set correctly? ( QT_PLUGIN_PATH )
  • Is the kdevelop version in the plugin manifest correct? ( .desktop file in KDE 4 style manifest )

Problem: when starting KDevelop KDE complains about missing .rc file for the plugin

  • Is the .rc file installed to the right directory? ( e.g.: /usr/share/kxmgui5/plugin/plugin.rc )
  • Is the .rc file named correctly and is it the same as set with setXMLFile in the plugin?
  • Is the .rc file named the same as the plugin’s name in IPlugin’s constructor?

Problem: plugin menu items don’t show up

  • Is the plugin loaded?
  • Check the possible problems in the section above


Upgrading kdevelop’s valgrind plugin to KF5

I’ve started to upgrade KDevelop’s valgrind plugin ( kdev-valgrind ) to KF5 so that the KF5 version of KDevelop can use it.
In short ‘Valgrind’ is a dynamic analysis tool that allows you to check your programs for memory errors, threading errors in runtime. It also allows you to cache and call profile. So it’s very useful. Without such tools it would be almost impossible to detect and debug these kinds of errors. ( other than reading all the code and spotting it of course )

Kdev-valgrind is a plugin for KDevelop, that integrates some of this functionality into KDevelop. I did not create the plugin I am just merely updating it, because it is very very important to have!

It took me some time, but finally I can compile and load it as the screenshots below will show. All I had to do was basically update it’s cmake project file with the KF5 libraries instead of the KDE4 ones, change some class/call references ( ok, lots of them ), and move away from the deprecated KDE widgets, in favor of the Qt ones. Very soon I will test it througly and then submit my changes for review to the KDevelop guys.



Checking the library dependencies of binaries ( executables, libraries )

Sometimes applications won’t start, plugins, libraries won’t load. Also sometimes the error messages just say they can’t be loaded. Ever wondered why they can’t load in such cases?
For situations like these we have tools that we can check said binaries with!

On Windows we have dependency walker, it’s a simple application really, you open the binary file that you want to check out, and then it shows the dependencies, even tells you if it can see problems:


On a Unix or Unix-like OS like Linux we have 2 tools to help, first there’s ldd, and objdump:
Ldd can show the dependencies recursively:


Objdump on the other hand shows the ones that are needed just by the binary in question:


They are very useful tools! So use them, next time you have such problems!


Building KDevelop KF5 on KDE4 Kubuntu 14.10


This is a bit tricky!
First of all, because you have to build lots of things, first make sure you have a build directory on a disk where there are lots of free space!
Then make that build directory and follow the instructions, with some creativity of course. These instructions aren’t written into stone, so when needed ( where your system / setup is different ), feel free to take the appropriate steps for your situation.

My setup is simple:
I have my home directory in /home/dfighter
I created a build directory there which is /home/dfighter/build, and I put everywhere in there into subdirectories.
The instructions will be based on this.

Building KF5

First of all you need to install some dependencies, like Qt5, and some other libraries:

sudo apt-get build-dep qtbase5-dev

sudo apt-get install libbz2-dev libxslt-dev libxml2-dev shared-mime-info oxygen-icon-theme libgif-dev libvlc-dev libvlccore-dev doxygen gperf bzr libxapian-dev fontforge libgcrypt20-dev libattr1-dev network-manager-dev libgtk-3-dev xsltproc xserver-xorg-dev xserver-xorg-input-synaptics-dev libpwquality-dev modemmanager-dev libxcb-keysyms1-dev libepoxy-dev libpolkit-agent-1-dev libnm-util-dev libnm-glib-dev ibxcb-xkb-dev

sudo apt-get install qtbase5-dev qtbase5-private-dev libqt5x11extras5-dev qtscript5-dev qttools5-dev libqt5svg5-dev libqt5xmlpatterns5-d

sudo apt-get install libjson-perl libxml-parser-perl qtdeclarative5-dev libqt5webkit5-dev

After you have all these dependencies you need to get ‘kdesrc-build’, which can download, build, and install KF5:

Clone it from KDE’s git repo:

cd ~/build
git clone git://
Download the configuration file for it:
cd kdesrc-build

Rename it to kdesrc-buildrc:

mv kf5-qt5-kdesrc-buildrc kdesrc-buildrc

Open ‘kdesrc-buildrc’ with a text editor and modify it, so that it reflects your desired environment:
Comment out the line that contains qtdir.
Change the source-dir parameter to whereever you want the tool to download the sources, in my case it’s

Change the build-dir parameter to wherever you want the tool to build the sources, in my case it’s/home/dfighter/build/KF5/build
Change the kde-dir parameter to wherever you want the tool to install the built binaries, in my case it’s /usr/local
Change the line

include extragear/utils/kdesrc-build/kf5-qt5-build-include


include kf5-qt5-build-include

Since you want to build only the framework, we can disable the rest, so open the file ‘kf5-qt5-build-inlcude’, and comment out the following lines:

include kf5-workspace-build-include
include kf5-applications-build-include
include kf5-kdepim-build-include

You can comment them out by puttin a # character right in front of the lines. Like this:

#include kf5-workspace-build-include
#include kf5-applications-build-include
#include kf5-kdepim-build-include

Now you can start to build the framework, by starting the script:

sudo ./kdesrc-build

( you only need sudo if you install to system directories )

The script will now start, and download, build, and install the framework’s parts one-by-one. This could take hours!

Building KDevPlatform

Install some dependencies, if they aren’t already installed

sudo apt-get install libqt5declarative5 qtquick1-5

Make a directory for, download, build, install grantlee 5:

cd ~/build
tar xvfz grantlee-5.0.0.tar.gz
cd grantlee-5.0.0
mkdir build
cd build
cmake ../
sudo checkinstall -D –strip=no –stripso=no –pkgname=grantlee5

If it complains about not finding ‘lrelease’, then find it, and create a symlink to where it’s looking. In my case I had to issue this command:

ln -sf /usr/bin/lrelease /usr/lib/i386-linux-gnu/qt5/bin/lrelease

Make a directory for, download, build, install the KF5 version of libkomparediff2:

cd ~/build
mkdir libkomparediff2
git clone git:// src
mkdir build
cd build
cmake ../src/
sudo checkinstall -D –strip=no –stripso=no –pkgname=libkomparediff2-kf5

Now make a directory for, clone, build and install KDevplatform:

cd ~/build
mkdir kdevplatform
cd kdevplatform
git clone git:// src
mkdir build
cd build
cmake ../src/
sudo checkinstall -D –strip=no –stripso=no –pkgname=kdevplatform-kf5

Building KDevelop

Make a directory for, clone, build and install:

cd ~/build
mkdir kdevelop
cd kdevelop
git clone git:// src
mkdir build
cd build
cmake ../src/
sudo checkinstall -D –strip=no –stripso=no –pkgname=kdevelop-kf5

Now all you have to do is add kdevplatform’s plugins’ path to the QT_PLUGIN_PATH environment variable.
If you didn’t change the default installation path, then it should be doable with a command like this:

export QT_PLUGIN_PATH=$QT_PLUGIN_PATH:/usr/local/lib/i386-linux-gnu/plugins

Alternatively, just so you don’t have to do this all the time, you can also add this to /etc/environment:


Now you can start kdevelop by issuing the command



NOTE: These instructions are based on the following guides:


KDE Plasma 5 crashes with VMware

Good news everyone!

As it is well known by now, the Plasma 5 version in KUbuntu 14.10 doesn’t really like when you resize the VM’s window. In fact it even let’s you know: plasma shell crashes.

Fortunately the KDE developers have solved this problem, and in later versions THIS particular problem no longer happens. In KUbuntu 14.04 beta the Plasma 5 version doesn’t crash anymore! Hooray!

Checkinstall is awesome

Developers on Unix or Unix-like Operating Systems, like Linux, typically build and install software packages with the make system. First you issue the command ‘make’ to build the package, then issue ‘make install’. Sadly this often means you end up polluting your system with the parts of that package, as often the maintainers don’t provide an uninstall target.

Fortunately for us, there’s a solution to this problem, and that is a little tool called ‘checkinstall’:

Basically it builds the install target in the Makefile ( which copies the files to the system ), packages the files, and install the package, so if you no longer want the files on your system, instead of having to look around for it’s parts and manually cleaning up, you can just remove the package. It also support the Debian, Red Hat and Slackware types of packages.
Isn’t it wonderful?

A word of warning:
Checkinstall strips the binaries by default, so when packaging debug binaries, the user should explicitly specify that they DON’T want them stripped! Keep that in mind!