New full changelogs for KDE Applications releases

With 14.12.0 we've introduced full changelogs for KDE Applications releases; you can see it at https://www.kde.org/announcements/fulllog_applications-14.12.0.php.

To generate this changelog we diff from previous release to the released one and use the commit message with a few annotations for stuff like REVIEW: BUG: etc.

This means the world is now going to see your commits more so spend 3 seconds when writing them instead of 0.5 ;)

If someone wants to improve the page (I'd like to have a checkbox that shows only commits that fix bugs) please contact me :)

The code lives in the release-tools repo (this is probably my longest python script, so be gentle ;))

KDE End of Year Fundraising cards are being sent out!

We ordered some samples to make sure they looked good, and here they are here!

If you want some, we will send them to you as gift if you donate to the KDE End of Year 2014 Fundraising

P.S: If you made a donation that qualifies for a postcard gift before this monday and have not received an email from me asking which design and to which address you want the postcards sent please contact me at aacid@kde.org

Keywords vs X-KDE-Keywords on .desktop files

Seem similar, do they? But they have a *radical* difference, one is "old" (X-KDE-Keywords) and the other is "new" (Keywords). The "new" one is also an xdg standard and as such the separator is ';'. The old one is just a KConfig string list and thus the separator is ','.

Great isn't it?

TL;DR
X-KDE-Keywords uses , for separation
Keywords uses ; for separation

Third design added for the KDE End of Year 2014 Fundraising Campaign!

I hope you know we're running a Fundraiser Campaign in KDE land. As a way to say thank you donors over 30€ get a postcard.

Today we've announced the last of the three designs you can choose as a gift when donating.

Donate and get a physical copy of it ;)

KDE Gardening Love Project: KRecipes

KRecipes has been in 2.0beta since 2010 so we decided it will be our next Love Project.

Objectives:
* We want to release 2.0 "quickly" and then 2.1 in one/two months.
* Migrate https://lists.sourceforge.net/lists/listinfo/krecipes-devel over to kde.org
* Migrate http://krecipes.sourceforge.net/ contents over to https://userbase.kde.org/KRecipes
* Add krecipes group to reviewboard that mails the KDE mailing list
* Add krecipes to jenkins that mails the kde.org mailing list
* Make sure bugs/reviewboards are defaulted to kde.org and go thorugh
* Port some of the Qt3Support code (make sure don't break stuff) :D

We will be updating this list at https://community.kde.org/Gardening/KRecipes

If you want to join the initiative please join the KDE Gardening mailing list and announce yourself :)

K3b 2.0.3 released

K3b 2.0.3 can be downloaded from http://download.kde.org/stable/k3b/k3b-2.0.3a.tar.xz

I don't have access to k3b.org so can't update the news there, shows why the Manifesto is such an important thing.

Changelog since 2.0.2:
* Fixed crash in MetaItemModel on submodel item removal
* Fixed Solid predicates for AudioCd and VideoDvd media. BUG: 265819
* Set error status when CDDB query fails.
* Prefer growisofs to wodim for DVD/BluRay burning.
* Fixed improper track number in CDDB track edit window title. BUG: 276681
* Fixed crash on detecting writing speeds. BUG: 272427
* Fix problem with HL-DT-ST BH10LS30. BUG: 268307
* Fixed compilation with new FFMPEG. BUG: 274817 BUG: 300731
* Allow using CD-R90 and CD-R99 media to full capacity. BUG: 276002
* Refactor the FreeBSD SCSI/CAM interface.
* Fix crash on dvd ripping
* fix sox detection with sox >= 14.4.0. BUG: 301544
* Support more media types. BUG: 261652
* Fix file system detection. BUG: 325616 BUG: 262607
* Surround output filename for transcode with double quotes. BUG: 326097
* Fix FILE name and type detection for cue sheet images. BUG: 337201
* Rip audio tracks in ascending numerical order. BUG: 319678
* Upstream patches from NetBSD.
* Make paranoia lib detection better.
* Don't preview if called process failed. BUG: 268680
* Fix Crash while remove songs in "Mixed mode CD proyect". BUG: 323117
* Use QElapsedTimer to calculate remaining time. BUG: 330239 BUG:315463
* Fix crash in lsof wrapper. BUGS: 340515

This marks the end of the "Gardening Love Project", I'll still be subscribed
to the k3b list but won't do any more than some lurking

I think someone should stand up and start thinking for a 2.1 release.

New postcard design added for the KDE End of Year 2014 Fundraising Campaign!

You probably know we're running a Fundraiser Campaign in KDE land. As a way to say thank you donors over 30€ get a postcard.

Today we've announced the second of three designs we are planning.

Donate and get a physical copy of it ;)

KDE Gardening Team: K3b

As mentioned on other KDE Gardening Team bugs we are focusing on getting K3b 2.0.3 release out.

The release will be on 4th November if all goes to plan.

Also we are going through the bugs doing two things:

• Checking if it still happens and asking people to give more info if needed

For bugs that are easy enough to reproduce (i.e. they do not involve having 13 CD burners or writing 50GB of data to a BlueRay disc) we are trying to reproduce them and if we can't ask the reporter for more information while setting the bug status to NEEDSINFO+WAITINGFORINFO

• Classifying it regarding it's gardening potential

For bugs that we can reproduce or we think they have enough information we are classifying them in three groups using the gardening flag in bugzilla "+" for crashes that are really critical to be fixed before the release[1], "?" for bugs that seem to be relatively easy and someone could pick up and fix if has time but are not a problem if not fixed, and "-" for bugs that are out of the scope of the gardening initiative. Being out of scope of the gardening initiative doesn't mean the bug is more or less valid, it just means that it is not for the gardeners or not very involved people to fix this bug and requires people with more commitment.

You can visit https://community.kde.org/Gardening/K3b for the relevant bugzilla links.

[1] This should be a mostly empty list since we already have 2.0.2 out and doesn't make sense to delay 2.0.3 until a bug is fixed given 2.0.3 will be already better than 2.0.2

Make the World a Better Place! - KDE End of Year 2014 Fundraising

At KDE sometimes we focus in the technical parts of Free Software. This is understandable since most of us are technical people doing a technical job.

But KDE also has a huge social impact, thanks to KDE there's schools that can teach touch typing , there's people out there that can do their accounting, there's business that can fill their taxes. KDE does provide quality software for all the world to use, making it a better place for all of us.

Donating to KDE is not for you, it is for the entire world.

As a way to say thank you, starting with € 30 KDE e.V. will send a KDE themed postcard to any given address. You will get an extra card for every additional € 10 donation.

More at https://www.kde.org/fundraisers/yearend2014/

Plasma 5.1 release parties!

Plasma 5.1 is coming up in less than a month, we have already two release parties in the planning, but i'm sure you have some fellow KDE users around you want to meet and have a beer with, so hop onto your local LUG, meetup, or something, organize a party and add it to https://community.kde.org/Promo/Events/Release_Parties/Plasma5.1

The KDE Gardening Team

At Akademy I did a short talk (8 min) + herded a BoF with a title called "Quality is in the eye of the beholder".

One of the topics was that we should try to get a team of people to care about the global state of KDE software, we've decided to call this "The Gardening Team".

The mandate of the team is to:
# Find *really* important bugs and ping people to fix them
# Find stale reviewboards and ping people to fix them
# Bugzilla gardening, close old products etc
# Find projects that need love and give them some

For that we have various ideas:

Try to find monthly a bug to get people to fix it, by highlighting it as "The Bug of The Month" or something. Of course this bug can't be stuff like "Make Okular support javascript", it has to be something that is really a pain point of the whole user base and we think we can find people to fix it, it makes no sense setting impossible goals ;)

Do routine passes over reviewboard trying to identify stale requests and finding people to help moving those.

Run something called "Love Project". The idea is to pick up a project that is somewhat stale, and for a short amount of time (let's say 2/3 months) try to get a new release out, fix the most important crashers/bugs, get the review boards released, etc. This goal of the team is *not* becoming the maintainers of the project, but maybe by virtue of the "Love Project" we can attract new contributors that decide to.

Since we're only a few maybe we can't do this all, so we're focusing on a particular "Love Project" by now, but you should join and help us do more!

Our current Love Project is K3b, that had 2.0.2 released a long time ago and has a 2.0 branch with a few more bugfixes that have been never released.

We are coordinating through https://todo.kde.org/?controller=board&action=show&project_id=26 at the moment but plan to get a mailing list soon (or invade an unused existing one).

If you're interested, comment and i'll give you a shout when the list is created, no mega skills are needed (though people with mega skills are also welcome ;))

KDE Applications 14.12 Release Schedule

The schedule for KDE Applications 14.12 release is ready. As always it's available in techbase at https://techbase.kde.org/Schedules/Applications/14.12_Release_Schedule.

The Freeze is only one month away!

Okular wants to "Save"

TLDR - Short version:
We are reworking part of the "Save As" code, and we are adding the long-requested "Save" button! The old "internal implicit save" behavior is being dropped and we need your input about what to do with data saved internally by previous Okular versions.

Please visit https://forum.kde.org/viewtopic.php?f=251&t=122750 and share your opinion on the poll/comments.

KDE Community plans for Releases in the Future

Long post about releases ahead, brace yourselves!

Last week we released KDE Applications and KDE Platform 4.14.

KDE Applications, KDE Platform and KDE Workspaces were sometimes collectively referred as the "KDE Software Compilation" or "KDE SC" in short form, which is arguably a bad name, but it is what it is.

The "Software Compilation" started dying a while ago and 4.14 marks its end.

KDE Platform was 'virtually frozen' a long time ago, but we kept increasing the version number for some reasons that are now not important, so KDE Platform 4.14.x will be the last version, of course we will go to very high 'x' if there is bugfixes to be done.

KDE Frameworks 5 is the successor of KDE Platform based on Qt5, it's already on 5.1 and the team plans to release a new 5.x version with both features and bugfixes every month.

KDE Workspaces was frozen at 4.11.x, in fact if you check your distro, you are probably using 4.11.somehighnumber, the plan is to keep doing releases for at least a year if there are bugfixes available.

Plasma 5 is the successor of KDE Workspaces based on KF5, it's currently at 5.0.1. The team plans releasing a stable 5.x.y version every month with bugfixes and a 5.x+1 feature release every three months.

That leaves us with the third component of the old releases, "KDE Applications", comprised of more than 100 applications. We want those to move to Qt5 and KF5 since it's simply a better world, but we're not going to do it all at once as we did in 4.0. We will give the maintainers the choice to move as they feel the quality of their KF5 port is good enough.

KDE Applications has been having feature releases every four months, with bugfix releases in the three months in between.

We don't plan changing that, but to highlight that applications can be used independently of the libraries used to build the desktop you are using, we're just going to use a time approach for version numbers, that is, next release will be "KDE Applications 14.12"

And that marks the end of the SC era since libraries, desktop and applications are now in a separate release schedule.

Also, if you are at akademy we're having a short session Sunday at 10:40, and I guess i'll schedule a BoF later in the week.

Akademy 2014 needs *you*

Akademy 2014 is just 3 weeks away.

If you haven't registered, you should register now, but since probably you are registered already, the next step is thinking if you want to be a volunteer.

Every big event needs volunteers: infodesk people, session chairs, video operators, etc.

If you want to make Akademy 2014 a success please go over to https://community.kde.org/Akademy/2014/Volunteers and sign yourself up!

KDE Randa Meetings 2014 - The End

Everything, good or bad, reaches to an end. So will do the KDE Randa Meetings 2014 in a few hours.

I can't say all the great stuff that has happened here the last few days, but i'll try to summarize:
* The book is looking great and something that would help us grow
* api.kde.org got some love and more to come in the future.
* Planning on making life easier for newbies trying to compile and contribute patches
* KF5 ports of lots of programs in progress
* Lots of planning on automating tasks
* GCompris being more KDE
* Bugfixing everywhere
* Awesome people all around

Thanks to everyone that donated in the Randa 2014 fund-raiser.

Thanks Mario for such a beautiful event.

And of course, do not forget about the next big KDE event you should to attend: AKADEMY 2014 in 3 weeks!

KDE Randa Meetings 2014 Day 4

Time flies when you're in good company, i planned to blog every day and now i realize we're on day 4 already.

Well, here comes some of the things i've been doing
* Participated in a few discussions about "the KDE SDK" Aleix seems very promising to recruit new developers :) Let's see if I can convince Aleix to blog about it
* KGeography port to KF5 started by David Gil is now complete.
* Started and finished Blinken port to KF5
* Made some patches for some frameworks while porting KGeography

Some of the cool things I've seen:
* kdenlive cleaning up their code to ease maintaince
* GCompris, a nice educational tool for children
* The KF5 Book is shaping up nicely
* Lots of KF5 porting and refining everywhere

Let's keep rolling!

KDE Randa Meetings 2014 Day 1

I wasn't planning on attending KDE Randa Meetings 2014 but last Wednesday I decided to, so bought some not so cheap plane and train tickets (don't worry, I payed from my own pocket) and here I am surrounded by awesome KDE hackers in the middle of the Swiss Alps.

I want to thank the more than 400 people that helped us fund KDE Randa Meetings 2014, you are awesome and directly responsible of improvements that are to come to millions of users in the world.

And remember we still need money to fund more sprints and stuff, so head over to our donations page and help us improve the world!

Help the KDE promo team do their work

We KDE developers have been working on the KDE Applications 4.14 release for the past four months, we've implemented features and important bugfixes. Now the release is near, and we have to write release notes so that our users get the message.

The thing about writing release notes is that you can't write about stuff you don't know, and KDE Applications is biiiiiiiiig so it's impossible for a small group of promo people to know all that happened to it in the last 4 months.

This means *you* developers have to help the promo team write the promo highlighting the most important changes you did to your app and writing them at https://notes.kde.org/p/release_4.14_kde-devel_notes so they can write a more distilled and promo-like text.

Please help them help you.

Logging in into Picasa 3.9 under Linux

A few years ago I showed my father Picasa under Linux, he liked it and started to use it to upload his photos, and has been using it for almost 6 years, even Google discontinued Picasa for Linux at version 3.0 (Picasa is at 3.9 now).

Unfortunately a few weeks ago seems Google decided to kill support for old APIs in the server side and Picasa 3.0 for Linux was giving back an error when trying to upload an image ("Could not find POST url" or similar). I suggested to wait to see if they would come back, but it seems they haven't and so i've had to fix it for him.

Since he's heavily invested in Picasa I've had to install Picasa for windows under wine to make it work. It has not been trivial to get to work so I'll share it here for others that committed the error of trusting privative software and services.

The story is this: Installing picasa 3.9 for windows under wine is pretty easy (next, next, next). The problem is once you are running it, being able to log in. First problem is that the webview using for login doesn't even show. Most of the interwebs suggest installing ie8 using winetricks to solve that and it indeed solves the problem of the webview not showing, but still i can't log in (interestingly the webview will tell you if you wrote the password wrong).

At this point i was stuck for a few hours, even found some dude that claimed he had installed Google Chrome Frame for Internet Explorer and that had fixed for him. But not for me.

After a few hours, I stopped trusting the internet and started to think. I have a windows installation laying around, and i can log in from there, and once logged in Picasa does not ask for the password again, so it must be storing something no?

So I made a copy of the Program Files folder and compared it after loggin in, folders where exactly the same. So it was not stored there, which makes sense since log in is per user not per machine. Next i tried in that weird Personal Folder (Windows $HOME) but could not find any change either. Last chance was the registry, i used http://www.nirsoft.net/utils/reg_file_from_application.html and saw that when logging in, Picasa writes a few entries in HKEY_CURRENT_USER\Software\Google\Picasa\Picasa2\Preferences namely GoogleOAuth, GoogleOAuthEmail, GoogleOAuthServices and GoogleOAuthVersion, so I copied these over to the wine installation (with "wine regedit") and now my father can run Picasa just fine again.

Lessons learned:
* Non Free Software will eventually come back and hit you, if possible don't use it for stuff that is critical to you
* Think about your problem, sometimes is easier than just googling random instructions from the internet.

My way to develop with git in KDE repos

From time to time there is the discussion of which workflow is better to develop with git, etc.

I'm not going to try to convince anyone on which workflow to use, i'm just going to explain what i do and explain why i think it's useful (and even more in the multi-developer KDE environment).

Let's picture the scenario we had a few days ago where there were lots of projects with three "live" branches, i.e. KDE/4.13, KDE/4.14 and master.

What is my way to develop?
* Bugfixes go to oldest "live" stable branch
* Features go to oldest "live" non frozen branch
* Branches are merged up

So let's say that I develop a new feature to support a whole new document format to Okular. Since that is a new feature it would go to the "oldest live non frozen branch", that in this case was master since KDE/4.13 and KDE/4.14 where already feature frozen. So I commit it to master and then "Branches are merged up" which in this case means nothing since there's no branch "up" from master.

Now let's say there's a crash bug when opening a file with three monitors. Since that is a bugfix, it'd go to the "oldest live stable branch", that in this case would be KDE/4.13. And then "Branches are merged up", so i would mean 4.13 into 4.14 and after that 4.14 into master. Ensuring that 4.14 and master also have the bugfix.

I think that this is a very useful way of developing using git branches for a lot of reasons, but the biggest of them is that for a random person it is easy to know if a "branch high in the hiearchy" has all the bugfixes or not, he just have to go to KDE/4.14 and to "git merge origin/KDE/4.13", if no change is brought over, it means that for sure all the bugfixes and code that was in the 4.13 release will be in the 4.14 release, otherwise it is hard to know.

So now that 4.13 is not going to be released anymore and 4.14 is a very young fork of master, i suggest that for every push you do to KDE/4.14 you go to the master branch and merge origin/KDE/4.14. This way you will have a master that is always fully merged with 4.14 and a third party person looking at your code (like the release manager) won't have to worry if it contains all the code or not.

Happy hacking!

And of course if you disagree with me, that's fine, not that i'm happy if my reasons did not convince you :)

KDE/4.14 branch forked

KDE/4.14 branch forked, master is now open. Next applications release will be a kdelibs4 and KF5 mix!

http://mail.kde.org/pipermail/kde-cvs-announce/2014/000147.html

KDE is a nice community, but we can do better!

Since a long time KDE.org has been referring to KDE as a team of people, a community, and not the software products we make.

I agree with this but sadly sometimes we struggle in being a nice community to live in.

There's a few things I think we can improve:

• Being better 'winners': We are a big community, at some point we have to take community-wide decisions, and it's impossible we will all agree on something. If you are part of the 'winning' group, be gentle with the people that 'lost', sure you think you are right, but they think the same and think the rest is doing a terrible mistake, so when you talk with them be polite and point out that the majority is going in the other direction, but that you still appreciate all the other stuff they do, etc. They already 'lost' so there's no need to put their head under your foot and do an evil laugh.
• Being better 'losers': We are a big community, at some point we have to take community-wide decisions, and it's impossible we will all agree on something. If you are part of the 'losing' group, be accepting that you 'lost' and try to carry on with the amazing work you do in other areas. Sure you are allowed to some venting, but it should be all within the limits of not trying to drag the discussion forever and not trying to destroy the project just because you disagree in one decision, so yes, you're allowed to some small complaining but understand that the majority decided different than what you think it's better, accept it and carry on, you'll be happier :)
• Assuming good by default: If a sentence can be read in two ways, do not assume it was said in the worse way, assume it was said in the good. Will help keeping the discussion sane and constructive.
• Not workarounding by default: If you find a bug or shortcoming in kdelibs, KF5, Qt or any other library, don't workaround it by default, please report it to the library people and try to work with them to fix it. Library code is not that hard and if you fix it in the source, everyone will benefit from the fix, not just the users of your software because you workarounded it and kept quiet about it to upper layers.
• Not caring enough for the global: We produce zillions of different projects of software. It's almost impossible to have a global overview of "what the bad bugs are", so if you know there is a bug that is bad, and it's affecting quite a bit of people, don't say "someone else will fix it" and ignore it, share it with the wider community and if the current maintainers are missing or overworked I'm pretty sure we can find someone to have a look and fix that bug that is making people sad.

This doesn't happen all the time, but it happens more than I would like, so I'm just raising it up so that people think about it and try to improve :)

Of course I'm not saying I'm not guilty of the things I mentioned, but as the wise-man said: "Don't do what i do, do what i say"

Web developer: Help KDE with a few hours of work

At KDE we're trying to get people to donate more (I hope I don't have to explain to this audience why), one of the ideas floating around is adding a small "impulse donate" button to kde.org similar to the one at http://www.videolan.org/ (only with euros and without a "why?" link for now)

I'm not a web devel by far (though have done my fair share of copy&pasting php, html and css for KDE and other personal projects) but I understand it should not be "that hard"™, it would be basically doing some modifications of the kde.org sources, the capacity framework and doing some reuse of the existing paypal donation page code.

Anyone up for the work? If so, please contact me!

Commit your approved Review Requests!

By looking at KDE git Review Board I realize we have over 4 pages of "ship it"-ed review requests that are still marked as not commited.

This is nuts!

I know some of them are still work in progress (yes, it sucks that reviewboard does not let you "unship it" when you find something wrong or when some newbie mistakenly gives himself a +1) but I am pretty sure at least 3 of those 4 pages are stuff that was coded, reviewed, approved and then no one committed it :/

So please go through your reviewboard changes and commit them, or ping the maintainer of the app if you don't have commit rights (and if the maintainer is unresponsive for some reason and it's obvious you had his "Ship it" just come to me and I'll commit it for you).

KDE Applications 4.13 released

Today we've released 4.13 which is probably the best KDE Applications release ever :)

It also marks the second release we do with a four months schedule instead of a six month one. I think we've ended up with a pretty nice cadence in which we are faster delivering features and bugfixes to users, which at the end is what is important, since the earlier people get the features the earlier they'll find the bugs (let's accept it, all software has bugs) and the earlier the bugs are found the earlier they can be fixed. So basically it's faster progress :)

We have also made good our promise to keep our tests passing, as you can see everything from this release is green (kde-workspace is not green but is not part of the 4.13 release). So kudos to all developers for being awesome in that regard too.

Let's all celebrate on this release but not forget we need to keep working full steam ahead on the releases of KDE Frameworks 5, Plasma 2014.06 and KDE Applications 4.14.

Finally I'd like to remind you that most of the people doing KDE development are volunteers and they invest their time in making this awesome software for you to use for free.

Lots of them even spend time to travel abroad to meet each other in Sprints were they do concentrated hacking for a few days, so if you appreciate the work they do in those Sprints please donate some money so we can actually help them travel and we can make more Sprints happen :-) http://www.kde.org/community/donations/

As anecdote, I had the pleasure of meeting the guys from the KTP Sprint this Friday and after dinner they went back to hacking instead of joining some of us for some beers. That is dedication!

ASAN and libraries (2nd part)

In ASAN and libraries I claimed you didn't need to compile a library with -fsanitize=address to get ASAN to work over it. Well it turns out that is only true in some cases and in some others like the one in this example you actually need it. So here comes a different example and the differences of using -fsanitize=address and not in the library code.

shared.cpp
#include "shared.h"

Foo::Foo()
{
int a[1];
a[2] = 3;
}



shared.h
class Foo
{
public:
Foo();
};



main.cpp
#include "shared.h"

int main(int, char **)
{
Foo f;
return 0;
}

Let's see what happens if we do

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1
g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3
g++ -fno-omit-frame-pointer -fsanitize=address main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

As the suggested in the previous blog entry.

Nothing, no error detected.

But if we change to

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1
g++ -fno-omit-frame-pointer -fsanitize=address -Wl,--no-undefined \
    -shared -o libshared.so shared.cpp -g3 -lasan -fPIC
g++ -fno-omit-frame-pointer -fsanitize=address main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

==13069== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe74fafa8
at pc 0x7fb0ef71f792 bp 0x7fffe74faf60 sp 0x7fffe74faf58
WRITE of size 4 at 0x7fffe74fafa8 thread T0
    #0 0x7fb0ef71f791 in Foo::Foo() /home/tsdgeos/test/shared.cpp:6
    #1 0x40074a in main /home/tsdgeos/test/main.cpp:5
    #2 0x7fb0ef37aec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #3 0x400638 in _start (/home/tsdgeos/test/a.out+0x400638)
Address 0x7fffe74fafa8 is located at offset 40 in frame <__base_ctor> of T0's stack:

Boom! We get the error :-) So my conclusion that ASAN wasn't needed on libraries was bad. You need it. Thanks Zecke for pointing me to my wrongness :-)

ASAN and plugins

In ASAN and libraries Milian asked if the reasoning for libraries also applied for plugins. Since I had no idea, I had to try it.

Here comes the output

main.cpp

#include <QDebug>
#include <QLibrary>

int main(int, char **)
{
    QLibrary l("libshared");
    qDebug() << l.load();

    return 0;
}

shared.cpp

#include "shared.h"

static Foo f;

Foo::Foo()
{
    int *a = 0;
    *a = 33;
}

shared.h

class Foo
{
public:
    Foo();
};

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1
g++ -shared -o libshared.so shared.cpp  -g3 -fPIC
g++ -fsanitize=address main.cpp -g3 -I /usr/include/qt4/QtCore/ \
    -I /usr/include/qt4/ -lQtCore

And then we run it!

$ LD_LIBRARY_PATH=. ./a.out 
ASAN:SIGSEGV
=================================================================
==7048== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7f199c1326aa sp 0x7fff37e557c0 bp 0x7fff37e557c0 T0)
AddressSanitizer can not provide additional info.
 #0 0x7f199c1326a9 in Foo::Foo() /home/tsdgeos/test/shared.cpp:8
 #1 0x7f199c1326da in __static_initialization_and_destruction_0(int, int) 
    /home/tsdgeos/test/shared.cpp:3
 #2 0x7f199c1326ef in _GLOBAL__sub_I_shared.cpp /home/tsdgeos/test/shared.cpp:9
 #3 0x7f19a132b139 (/lib64/ld-linux-x86-64.so.2+0x10139)
 #4 0x7f19a132b222 (/lib64/ld-linux-x86-64.so.2+0x10222)
 #5 0x7f19a132fc6f (/lib64/ld-linux-x86-64.so.2+0x14c6f)
 #6 0x7f19a132aff3 (/lib64/ld-linux-x86-64.so.2+0xfff3)
 #7 0x7f19a132f3ba (/lib64/ld-linux-x86-64.so.2+0x143ba)
 #8 0x7f199d1a602a (/lib/x86_64-linux-gnu/libdl.so.2+0x102a)
 #9 0x7f19a132aff3 (/lib64/ld-linux-x86-64.so.2+0xfff3)
 #10 0x7f199d1a662c (/lib/x86_64-linux-gnu/libdl.so.2+0x162c)
 #11 0x7f199d1a60c0 (/lib/x86_64-linux-gnu/libdl.so.2+0x10c0)
 #12 0x7f199e0156b7 (/usr/lib/x86_64-linux-gnu/libQtCore.so.4+0x16e6b7)
 #13 0x7f199e010599 (/usr/lib/x86_64-linux-gnu/libQtCore.so.4+0x169599)
 #14 0x4011c0 in main /home/tsdgeos/test/main.cpp:8
 #15 0x7f199d5e8ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
 #16 0x401078 in _start (/home/tsdgeos/test/a.out+0x401078)
SUMMARY: AddressSanitizer: SEGV /home/tsdgeos/test/shared.cpp:8 Foo::Foo()
==7048== ABORTING

So it seems that "plugins are just libraries" applies here :)

ASAN and libraries

Yesterday we saw how to get line numbers in the stacktrace when using ASAN and gcc, today we're going to see how to deal with ASAN and libraries. For that we're going to use these three very simple files

shared.cpp

#include "shared.h"

Foo::Foo()
{
    int *a = 0;
    *a = 33;
}

shared.h

class Foo
{
public:
    Foo();
};

main.cpp

#include "shared.h"

int main(int, char **)
{
    Foo f;
    return 0;
}

We do the initial compilation:

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3
g++ main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

and it segfaults :)

Now we want to use ASAN to find out what's wrong, where do we add the -fsanitize=address -fno-omit-frame-pointer? Logic would say that we add it to both places, but actually it's only necessary to add it to the final binary, i.e

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3
g++ -fno-omit-frame-pointer -fsanitize=address main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

and we get

==10226== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7f497563f66a sp 0x7fff77cc4310 bp 0x7fff77cc4310 T0)
AddressSanitizer can not provide additional info.
    #0 0x7f497563f669 in Foo::Foo() /home/tsdgeos/test/shared.cpp:6
    #1 0x40074a in main /home/tsdgeos/test/main.cpp:5
    #2 0x7f497529aec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #3 0x400638 in _start (/home/tsdgeos/test/a.out+0x400638)
SUMMARY: AddressSanitizer: SEGV /home/tsdgeos/test/shared.cpp:6 Foo::Foo()

There you go, no need to add the -fsanitize=address flag to the library compilation :)

Now, until a few minutes ago I did not know this, I actually was adding -fsanitize=address to the library itself; that comes with a few problems that i'll explain how i solved (just for completeness, since the above example shows you don't need it)

My logic was that by looking at main.cpp i knew nothing could be wrong there so i decided i wanted sanitize the library, my first attempt was:

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3 \
-fno-omit-frame-pointer -fsanitize=address

which gives a linking error

/tmp/cc18Wen3.o: In function `Foo::Foo()':
/home/tsdgeos/test/shared.cpp:6: undefined reference to `__asan_report_store4'
/usr/bin/ld: /tmp/cc18Wen3.o: relocation R_X86_64_PC32 against undefined symbol
`__asan_report_store4' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

OK, so we are told to recompile with -fPIC, easy peasy

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3 \
-fno-omit-frame-pointer -fsanitize=address -fPIC

Which still fails to link!

/tmp/ccNkpRZo.o: In function `Foo::Foo()':
/home/tsdgeos/test/shared.cpp:6: undefined reference to `__asan_report_store4'
/tmp/ccNkpRZo.o: In function `_GLOBAL__sub_I_00099_0_shared.cpp':
/home/tsdgeos/test/shared.cpp:7: undefined reference to `__asan_init_v1'
collect2: error: ld returned 1 exit status

OK, so if ASAN symbols are missing, let's just compile libasan in

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3 \
-fno-omit-frame-pointer -fsanitize=address -fPIC -lasan

Links!

Next since I know nothing is wrong in main.cpp I don't need ASAN in there

g++  main.cpp -lshared -L . -g3

Compiles!

But when run it segfaults :-/ And if you debug it you'll see a stack trace like

#0  0x0000000000000000 in ?? ()
#1  0x00007ffff4894bf1 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#2  0x00007ffff4894e32 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#3  0x00007ffff4895d9b in __asan_init_v1 () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#4  0x00007ffff7bd8776 in _GLOBAL__sub_I_00099_0_shared.cpp(void) () at shared.cpp:7
#5  0x00007ffff7dea13a in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffffffde18, env=env@entry=0x7fffffffde28) at dl-init.c:78
#6  0x00007ffff7dea223 in call_init (env=, argv=, argc=, l=) at dl-init.c:36
#7  _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffde18, env=0x7fffffffde28) at dl-init.c:126
#8  0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffe1ca in ?? ()
#11 0x0000000000000000 in ?? ()

So something weird in ASAN thing is going on, let's compile -lasan in also

g++  main.cpp -lshared -L . -g3 -lasan

Same crash :-/

Ok, so then you think, well, let's just add the fsanitize in. And then it works, but as demonstrated a few lines ago, the whole thing of adding -fsanitize=address and -lasan to the library was unneeded since all that was required was just adding -fsanitize=address to the binary when it's compiled and that's it :)

ASAN and gcc: How to get line numbers in the stacktrace

ASAN or Address Sanitizer is a nice project by Google that is a memory error detector for C/C++. According to their web it finds:

• Use after free (dangling pointer dereference)
• buffer overflow
• Stack buffer overflow
• Global buffer overflow
• Use after return
• Initialization order bugs

Also it's much faster than valgrind :-) Unfortunately it's not as easy to use as valgrind since it requires a rebuild of your code.

The basic instructions to use ASAN are:

Use the -fsanitize=address switch

together with the suggestion of

To get nicer stack traces in error messages add -fno-omit-frame-pointer.

As a simple example let's see what happens when we run

int main(int, char **)
{
    int a[3];
    a[3] = 4;
    return 0;
}

compiled with

g++ -fno-omit-frame-pointer -fsanitize=address main.cpp

The result:

==8403== ERROR: AddressSanitizer: stack-buffer-overflow
on address 0x7fffbe7c7d8c at pc 0x400779
bp 0x7fffbe7c7d40 sp 0x7fffbe7c7d38
WRITE of size 4 at 0x7fffbe7c7d8c thread T0
    #0 0x400778 (/home/tsdgeos_work/test/a.out+0x400778)
    #1 0x7f2f5cfa6ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
    #2 0x400638 (/home/tsdgeos_work/test/a.out+0x400638)
Address 0x7fffbe7c7d8c is located at offset 44 in frame 
 of T0's stack:
  This frame has 1 object(s):
    [32, 44) 'a'

In this case it's pretty obvious what's wrong with just looking at the code and ASAN is even telling us it is a bad write just after the 'a' object, but note that we are not getting the line number of where the error happens. You'll say, that's why you didn't use the -g switch! So let's see what do we get after compiling with

g++ -g3 -fno-omit-frame-pointer -fsanitize=address main.cpp

The result:

==8467== ERROR: AddressSanitizer: stack-buffer-overflow
on address 0x7fff59ccaa2c at pc 0x400779
bp 0x7fff59cca9e0 sp 0x7fff59cca9d8
WRITE of size 4 at 0x7fff59ccaa2c thread T0
    #0 0x400778 (/home/tsdgeos_work/test/a.out+0x400778)
    #1 0x7f6f75601ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
    #2 0x400638 (/home/tsdgeos_work/test/a.out+0x400638)
Address 0x7fff59ccaa2c is located at offset 44 in frame 
 of T0's stack:
  This frame has 1 object(s):
    [32, 44) 'a'

Same thing :-/

Here is where people may give up or think to switch to clang and try there, but since clang is sometimes more picky with the code (not bad per se) it may be a lot of work to get your code to compile under clang, if you keep digging you'll read some news about GCC not having a ASAN symbolizer [yet], but clang has one and you can still use it with GCC, so if you

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1

and then run the binary again (the one we just compiled with -g3)

The result:

WRITE of size 4 at 0x7fff4f5f0ebc thread T0
    #0 0x400778 in main /home/tsdgeos_work/test/main.cpp:5
    #1 0x7f3d4dce2ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #2 0x400638 in _start (/home/tsdgeos_work/test/a.out+0x400638)
Address 0x7fff4f5f0ebc is located at offset 44 in frame 
 of T0's stack:
  This frame has 1 object(s):
    [32, 44) 'a'

And now we have line numbers :-)

Akademy-es 2014 in Málaga

This year, the 9th Akademy-es will take place in Málaga from 16 to 18 May.

Málaga is the city that hosted Akademy 2005 and were a few few crazy people met and thought about doing Akademy-es 2006 next year in Barcelona, and after that, 9 years in a row. Not bad :-)

I'm definitely going and you should if you're interested in KDE too. And of course you should think about submitting a talk :-)
Finally if you have a company you may want to join and sponsor the event, have a look at the sponsor page.

Registration is still not open but will be in a few days/weeks.

Hope to see you there :-)

How to strike out text in Okular

We just had a user report a wish item in bugs.kde.org asking for Okular to come with a text strike-out annotation by default. I just closed the bug saying that he can create his own annotations by Settings -> Configure Okular -> Annotations -> Add ->
Text Markup -> Strike Out -> Set Color -> OK



Of course we could still ship it, but if you have a look at that "Add Annotations" dialogs there's lots of lots of possibilities so people should just create the ones they see the need for instead of us shipping lots that may not be that useful.

KDE Applications and Platform 4.13 Schedule

You can find the release schedule for KDE Applications and Platform 4.13 at http://techbase.kde.org/Schedules/KDE4/4.13_Release_Schedule

This schedule consolidates the changes made for 4.12 since it seems to have worked well.

Also remember that 4.13 will be applications and kdelibs only; KDE Workspace (aka Plasma) will be getting 4.11.x LTS releases until August 2015