qt 4.8.x stops smplayer from loading in xfce4 session

[wcg]

I had an issue recently with smplayer linked
with qt-{core, dbus, script, gui}-4.8.x being
unable to load correctly from the xfce4 menu.
This happened with both smplayer-0.7.1 and
smplayer-0.8.0.

The qt versions that were problematic were:

qt-core-4.8.1 (plus a few patches applied by
the Gentoo Linux maintainers of the qt library
packages, ie qt-core-4.8.1-r3, where the "-r[digit]"
refers to the Gentoo portage package version)
qt-dbus-4.8.1
qt-script-4.8.1
qt-gui-4.8.1 (plus one Gentoo-applied patch, qt-gui-4.8.1-r1)

I downgraded qt4 to the versions below, which had been working
with smplayer-0.7.1 before the update (qt4, smplayer, and
xfce4 were all updated at the same time):

qt-core-4.7.4-r1
qt-dbus-4.7.4
qt-script-4.7.4
qt-gui-4.7.4-r1

I linked smplayer-0.8.0 with these older versions of the qt4
libraries, and smplayer-0.8.0 loaded correctly from the
xfce4 application menu.

I did not see what the error with qt-4.8.x was in the smplayer
log or in the Xorg log. The visible error is that if one selects
smplayer from the application menu (or tries to run it directly
with xfce4's run dialog), nothing happens. No smplayer window
is displayed at all. Downgrade the qt libraries to 4.7.x, re-link, and
smplayer-0.8.0 loads in an xfce4 session the way that one expects
it to load.

(I do not know if this is a bug, who's bug exactly, or simply a change
in a support library api that the smplayer source needs to be aware
of to function correctly.)

[rvm]

Does it give any error if you run smplayer in a terminal?

[wcg]

I re-linked smplayer-0.8.0 to qt-core-4.8.1 and associated
qt-4.8.x libraries, renamed the smplayer binary in /usr/bin
to "smplayer.bin", made a shell script wrapper to strace it,
and made "/usr/bin/smplayer" a symbolic link to the shell script.

An strace of smplayer linked with qt-core-4.8.1, etc.,
is posted at http://pastebin.ca/2157274

(The strace log is from attempting to start smplayer
in a terminal, since I did not know whether xfce
would ignore the shell script and call smplayer.bin
directly from the auto-generated application menu.
Ends in a segfault.)

Other context:
linux kernel 3.1.6, no patches or closed-source drivers
Running on amd x86_64 cpu
xorg-server-1.11.2-r2
glibc-2.15-r2
Compiled for x86_64 by gcc-4.5.3, no 32-bit library support
(32-bit executable support is enabled in the kernel for the grub
boot loader, but nothing else on the system is compiled
for 32-bit x86.)
CFLAGS="-march=native -O2 -fno-strict-aliasing -pipe -Wall"
CXXFLAGS=${CFLAGS} -fpermissive

[rvm]

Did you try to compile smplayer with Qt 4.8?

[wcg]

Did you try to compile smplayer with Qt 4.8?

Yes, the strace log at the URL above is from smplayer-0.8.0
linked to the Qt 4.8 libraries. (The Qt 4.7 libraries were
completely removed from the system, the Qt 4.8 libraries
were compiled and installed, and smplayer was recompiled
and reinstalled. The only Qt libraries that the makefile had
available to it at link time were the Qt 4.8 libraries, and the only
Qt libraries that ld.so had available at run time were the Qt 4.8
libraries.) Note that smplayer-0.7.1 also will not load when
linked to Qt 4.8 libraries, but it will load when linked to the
Qt 4.7.4 libraries.

Everything on the system is built locally from source. No
downloaded binaries that have been built elsewhere.
The portage checksums for the source packages match
what they should be.

I have the smplayer-0.8.0 build log if that will help you.

smplayer-0.8.0 does work when linked to the older Qt 4.7
libraries (to whatever extent mplayer works, of course).
I have been running it that way for a few days, no
problems with .mp3 streams, YouTube videos, audio cds,
etc.

PS: I called strace with:

Code: Select all

#!/bin/bash
exec strace -f -o /tmp/smplayer_strace.log /usr/bin/smplayer.bin "$@"


[rvm]

In Ubuntu 12.04, smplayer works ok with Qt 4.8.1. So I don't think it's a problem of Qt 4.8.

[wcg]

In Ubuntu 12.04, smplayer works ok with Qt 4.8.1. So I don't think it's a problem of Qt 4.8.

Ok, maybe it is one of those Gentoo fix-it patches. For reference, the Gentoo
build applies two patches to qt-core-4.8.1:

moc-workaround-for-boost-1.48
qt-core-4.8.1-localized-time

The qt-gui-4.8.1 build also applies two patches:

qt-gui-4.7.3-cups-patch
qt-gui-4.8.1-fix-calligra-crash

The kernel log reports smplayer trying to write to a null pointer
when linked to the qt-4.8.x libraries. Maybe one of the fixes needs
to be re-fixed.

Thanks for your time.

[wcg]

I still have this bug. I upgraded to qt-*-4.8.2, which has no Gentoo-specific
patches applied, and smplayer segfaulted in the same function.

Here is a backtrace (-O2 -ggdb), smplayer-0.8.0 linked to
qt-core-4.8.2, qt-dbus-4.8.2, qt-script-4.8.2, and qt-gui-4.8.2:
http://pastebin.ca/2160390

(No system changes other than upgrading from kernel 3.1.6
to kernel 3.2.12. Smplayer behavior was the same on both kernels.)

Any ideas?

[rvm]

Not sure, maybe the problem is in QtSingleApplication, could you try to compile smplayer without it? (comment the line DEFINES += SINGLE_INSTANCE in smplayer.pro)

[wcg]

comment the line DEFINES += SINGLE_INSTANCE in smplayer.pro

No change. (After "make clean" in the smplayer src/ directory,
commenting that line out in smplayer.pro, and "make", smplayer
still exits with a SIGSEGV before opening the smplayer window).
I watched the make log to be sure it was picking up that change
at compile time.

Back to qt 4.7.4 until something else suggests itself. Someone on
a Gentoo forum suggested that the glib version would be one possible
source of changes in qt behavior. I am running with glib-2.30.3.