Evan Teran's Blog

(Not so much) Fun with QSharedPointer

Evan Teran — Thu, 15 Dec 2011 20:04:22 +0000

Qt has a wonderful way of dealing with memory management. The core idea is simple. Most objects have a parent, and when the parent gets destroyed, it will first destroy all it’s children. Using this technique, you can often write your Qt applications with little to no concern for memory management. Often, you literally don’t have to have a single delete in your entire application. That’s pretty sweet!

In addition, since Qt 4.5 QSharedPointer was introduced, which is very similar in concept to boost::shared_ptr (and thus std::tr1::shared_ptr). I have long been a huge fan of the idea of smart pointers. They solve the need to worry about memory management for almost all usual cases. Unfortunately, when you combine these two concepts, sometimes you can go awry. I was surprised by this one, so I figured I’d shared my findings .

First we need some basic code to demonstrate the issue… Let’s suppose we have two trivial classes which inherit from QObject and thus participate in the Qt style memory management system. They might look like this:

Parent.h

class Parent : public QObject {
	Q_OBJECT
public:
	Parent(QObject *parent = 0) : QObject(parent) {
		std::cout << "Parent()" << std::endl;
	}

	virtual ~Parent() {
		std::cout << "~Parent()" << std::endl;
	}
};

Child.h

class Child : public QObject {
	Q_OBJECT
public:
	Child(QObject *parent = 0) : QObject(parent) {
		std::cout << "Child()" << std::endl;
	}

	virtual ~Child() {
		std::cout << "~Child()" << std::endl;
	}
};

And finally, we have some code to make use of our wonder code above:

void MyAwesomeFunction(Child *o) {
	std::cout << "Using Object!" << std::endl;
}

int main() {
	Parent *const parent = new Parent(0);
	Child *const child = new Child(parent);
	MyAwesomeFunction(child);
	delete parent;
}

The output of this simple program should be as follows:

Parent()
Child()
Using Object!
~Parent()
~Child()

As you can see, despite only explicitly deleting the parent, the child object gets cleaned up as well! This is great, heck if we made parent an automatic object, we wouldn't even need to explicitly delete it either. But what if MyAwesomeFunction for whatever reason, took a QSharedPointer instead of a raw pointer? You may just assume that you could write your code to be like this:

void MyAwesomeFunction(const QSharedPointer &o) {
	std::cout << "Using Object!" << std::endl;
}

int main() {
	Parent *const parent = new Parent(0);
	QSharedPointer child(new Child(parent));
	MyAwesomeFunction(child);
	delete parent;
}

well, if you made that assumption like I did, you'd be wrong! At best, this code leads to output like this:

Parent()
Child()
Using Object!
~Parent()
~Child()
QObject: shared QObject was deleted directly. The program is malformed and may crash.

At worst, it will crash. The question is, why is this broken? It all boils down to reference counting and who is doing the counting. What we have here, is two separate reference counts on the same object. One maintained by the parent object, one maintained by the QSharedPointer, and they will certainly disagree on when to delete the object. Leading to double free and use after free errors. No Bueno.

But it gets more complex than that! Qt memory management tries its best to let you do manual memory management while still maintaining it's own system. So if you delete child before the parent is deleted, that's just fine. The child's destructor will deregister itself from its parent's child list. So the following is well formed:

void MyAwesomeFunction(Child *o) {
	std::cout << "Using Object!" << std::endl;
}

int main() {
	Parent *const parent = new Parent(0);
	Child *const child = new Child(parent);
	MyAwesomeFunction(child);
	delete child;
	delete parent;
}

But if the parent happens to be delete'd first, then all hell breaks loose:

void MyAwesomeFunction(Child *o) {
	std::cout << "Using Object!" << std::endl;
}

int main() {
	Parent *const parent = new Parent(0);
	Child *const child = new Child(parent);
	MyAwesomeFunction(child);
	delete parent;
	delete child;
}

Segmentation fault

When we use QSharedPointer, this is essentially what we are doing if the object has a parent! The scary thing is, if the parent outlives the QSharedPointer on average, then the bug doesn't show up (since then it will act like case #1). Fortunately, starting with Qt 4.8, if you attempt to write this type of broken code, you will see an assert like this:

QSharedPointer: pointer 0x2384d70 already has reference counting

Which at the very least gives us a basic idea that there is something wrong, and it involves a QSharedPointer. It's a start.

The simplest approach to the problem is to simply not mix and match the two memory management schemes. If you need a QSharedPointer, don't set the parent. Like this:

void MyAwesomeFunction(const QSharedPointer &o) {
	std::cout << "Using Object!" << std::endl;
}

int main() {
	Parent *const parent = new Parent(0);
	QSharedPointer child(new Child());
	MyAwesomeFunction(child);
	delete parent;
}

which will happily output the following:

Parent()
Child()
Using Object!
~Parent()
~Child()

Combining Qt’s Signals and Slots with c++0x lamdas

Evan Teran — Mon, 28 Mar 2011 03:26:52 +0000

Qt is a fantastically designed library. However, every now and then I think of something that I wish they offered that they don’t. It’s almost always something small and easily worked around, but it would be nice if it were just there. This time around, that feature is the ability to connect a signal to a function which is not a member of a class/struct. Specifically, I think it would be really cool if I could connect it to a c++0x lambda! Especially now that the ISO C++ committee approved the C++0x final draft.

Fortunately, this turned out to be a fairly easy. Firstly we need an object to receive the signal since Qt mandates that all slots are member functions. Seems easy enough, so we’ll start with that:

class connect_functor_helper : public QObject {
    Q_OBJECT
public:
    // TBD
};

And we of course need a function to do the connection, we’ll template it so it can accept anything, a function, a functor, or even a lambda .

template 
bool connect(QObject *sender, const char *signal, const T &reciever, Qt::ConnectionType type = Qt::AutoConnection) {
    // TBD
}

The pieces are all here, all we have to do is put them together. I do wish that MOC supported templated types, that would make this slightly easier (since we want to allow anything to be connected to). So I ended up resorting to using boost::function. When we fill in the blanks, the class looks like this:

class connect_functor_helper : public QObject {
	Q_OBJECT
public:
	connect_functor_helper(QObject *parent, const boost::function &f) : QObject(parent), function_(f) {
	}

public Q_SLOTS:
	void signaled() {
		function_();
	}

private:
	boost::function function_;
};

So two things are happening here that’s noteworthy.

We make the helper object a child of the some QObject (ideally the sender of the signal), so that it will be automatically deleted when the parent object gets destroyed.
We have a simple boost::function to store the function we want and call it from a slot called signaled(). We use this because it allows us to be generic without resorting to templates.

The last thing is to just add the connection, which is easy enough .

template 
bool connect(QObject *sender, const char *signal, const T &reciever, Qt::ConnectionType type = Qt::AutoConnection) {
	return QObject::connect(sender, signal, new connect_functor_helper(sender, reciever), SLOT(signaled()), type);
}

Huzzah! We now can connect a Qt signal to anything that is callable like a function with the prototype void f(), even lambdas! Of course this can be expanded to deal with parameters as well, this is just the tip of the iceberg. So once we put all of the above into a header, we finally have the following demonstration program which works when QMAKE_CXXFLAGS contains --std=c++0x:

#include 
#include 
#include 
#include "LambdaConnect.h"

int main(int argc, char *argv[]) {
	QApplication app(argc, argv);
	QPushButton w("Push Me");
	w.show();
	connect(&w, SIGNAL(clicked()), []{
		std::cout << "clicked" << std::endl;
	});
	app.exec();
}

Enjoy!

GMP error handling frustrates me

Evan Teran — Mon, 21 Mar 2011 16:23:32 +0000

The GNU Multiple Precision Arithmetic Library (GMP) is a wonderful library. It offers arbitrary precision math in a relatively simple, easy to use package. It is currently used in kcalc as the core for all basic math operations. The only problem is, the error handling it offers, is broken by design.

What could possibly be so broken in such a useful library? abort(). That’s right, this simple C library function is the thorn in my side that makes using GMP annoying. So what’s so bad about this function?

Here’s the problem, when allowing the user to enter arbitrary values to calculate with (like kcalc), it is trivial to create numbers that are so big, that it would take more RAM than you have to represent it in memory. For example: 549,755,813,888!, that’s right, the factorial of that number. As you can imagine, that is a ridiculously large number. So big in fact that GMP gives up before it even starts.

It’s actually good that GMP gives up before wasting the user’s time, the problem is how it gives up. It does so by printing a message to stderr and calling abort(). Keep in mind, this is a library, not an application. This means that is is simply part of another application which could be doing anything. Yet when GMP fails, it gives the the application, (you know that thing that the user cares about) absolutely no easy opportunity to deal with the issue. All the user sees is a crash.

This is what I’ve had to resort to in order to work around this:

static jmp_buf abort_factorial;
static void factorial_abort_handler(int)
{
    longjmp(abort_factorial, 1);
}

detail::knumber *detail::knuminteger::factorial() const
{
	// ----snip----
	// some basic sanity checking here ...
	// ----snip----

    struct sigaction new_sa;
    struct sigaction old_sa;

    sigemptyset(&new_sa.sa_mask);
    new_sa.sa_handler = factorial_abort_handler;
    sigaction(SIGABRT, &new_sa, &old_sa);

    if(setjmp(abort_factorial)) {
        sigaction(SIGABRT, &old_sa, 0);
        return new knumerror(UndefinedNumber);
    }

	// ----snip----
	// attempt to do interesting work here ...
	// ----snip----

    sigaction(SIGABRT, &old_sa, 0);

    return tmp_num;
}

I have to resort to setting up a signal handler before doing the work and using longjmp() to clean up the mess neatly if an abort happens. I can’t even use c++ exceptions to handle this because SIGABRT isn’t trapped by them. I suppose I could do something “clever” and replace the libc’s abort() function with my own, but that’s just another hack, I want a clean approach.

Fortunately, I don’t just bring problems, I also bring solutions . What GMP should do is offer a “fatal error” handler. Something like this would be great:

void gmp_fatal(const char *reason) { (*gmp_fatal_ptr)(reason); } where gmp_fatal_ptr is a function pointer that can be set by the application.

Heck by default, it can point to a function which prints the reason to stderr and calls abort, this would mean that most users and application writers wouldn’t even see the difference. But at least give me the option to deal with it in a reasonable fashion that isn’t a crash.

HTML5 and undefined tags

Evan Teran — Tue, 08 Mar 2011 21:38:47 +0000

So I was just reading up on the upcoming HTML5 standard and am generally very pleased with the work they’ve done. But a though occurred to me, since HTML5 is effectivly going “version-less“, web designers are going to have to use javascript in order to detect features client side and either inject elements into the DOM when they are there, or inject some fallback code if they are not. There has been a lot of nice work on this front, specifically modernizr is a very cool library for this. But maybe there is a cleaner, better way.

First let me be clear, that why I am about to suggest is not currently valid HTML, it is what I think HTML5 should be, not what it is. So please don’t get upset if you try this and it doesn’t work.

So I want my idea to be simple and not require javascript. Using javascript to detect features is nice and all, but I don’t want to depend on this. I would like to be able to just write my html, and have it gracefully fallback if the feature is not there. This sounds complicated, but I believe that it isn’t.

A simple rule could be introduced to aid in this effort. While I’m sure there are corner cases that I am not considering, I think something like this would be good enough for:

If a unknown tag is encountered, treat it as a
. If the unknown tag is self closing, then treat as if it had a closing. When treating an unknown tag as a
, ignore attributes not applicable to a
. If a tag introduced in HTML5 is encountered and understood, then simply ignore any inner HTML that doesn’t apply.

This would allow us to write something like the following:



  
  
  
  Sorry, but your browser doesn't appear to support HTML5 video....

So, how would this be parsed using the rules I’ve supplied? Suppose the browser doesn’t implement the tag, well then it would be parsed like this:



  
  
  
  Sorry, but your browser doesn't appear to support HTML5 video....

So we have a bunch of

tags. We could use CSS to make it have the same dimmensions as the video would have if we like (making it still fit nicely in the design), and we have some fallback code there. Heck, the fallback code could a