Hi Sebastian,

The segfault occurs because you don't have a QtGui.QApplication's instance in
your program. The QtGui.QIcon.themeSearchPaths() function internally, at some
point, does something that needs a QtGui.QApplication's instance. The possible
workaround would be to add a sanity check to see if there's a
QtGui.QApplication's instance in somewhere, if there's one, then we'd call it.
However, we can't simply to add overhead just to fix bogus programs. This also
happens when you instantiate a QtGui.QWidget without instantiating a
QtGui.QApplication previously.

Anyway, thanks for the report.

Marking this bug as WONTFIX for now.


           - Paulo Alcantara

I personally think, throwing exceptions in those cases instead of segfaulting
would be more pythonic. I guess, most people don't want a hard interpreter
crash, when they had done something wrong. What about raising RuntimeError or
anything related to that in those situations?

Hi Sebastian,

(In reply to comment #2)
> I personally think, throwing exceptions in those cases instead of segfaulting
> would be more pythonic. I guess, most people don't want a hard interpreter
> crash, when they had done something wrong. What about raising RuntimeError or
> anything related to that in those situations?

We can't simply to add useless overhead to fix badly-written PySide programs.
As you must know, there are many Qt objects that need to have a QApplication
instance to be used in somewhere. So if I do that for QIcon.themeSearchPaths()
I'd have to do this for all those objects that need to have a QApplication
instance. Then once we do that, for each instantiated Qt object there must be a
check for a QApplication instance, so slowing down the perfomance just to make
sure one is writting correctly his/her program. This sort of thing has been
discussed many times between me and other PySide developers and we decided not
to do that.


           - Paulo Alcantara

I think you're right. That behavior is actually an issue related to Qt
internals and wrappers should normally not intend to work-around that. But as
the hard crash appears somewhat unusual to Python users, you eventually want to
place some kind of general warning somewhere in the docs (though, I'm not
certain if that is really needed).

To be honest, my example seems a bit constructed anyway. I stumbled over that
when doing some testing inside the Python shell. However, due to the fact that
interpreter crashes are well-known at least for libraries that deal with
graphical interfaces when used in "unusual" ways I think it's alright to not
necessarily implement "rescue code" for that.