(This bug has also been reported upstream: https://bugs.kde.org/show_bug.cgi?id=230005 However, there is no response. To make sure this isn't a Gentoo-specific bug, if possible, try the provided sample code.) When using the Xine backend in Phonon, Phonon::MediaObject::setCurrentSource() hangs when called the second or third time (even when not calling it on the same MediaObject instance) and never returns when used in combination with a QBuffer. The code that triggers it is this: Phonon::MediaObject* getMedia( const QString& fname, int pos, int size ) { QFile file(fname); file.open(QIODevice::ReadOnly); file.seek(pos); // A *.wav file is embedded at that // position. Phonon::MediaObject* med = new Phonon::MediaObject(0); QBuffer* buf = new QBuffer(med); buf->setData(file.read(size)); // The embedded wav is // 'size' bytes big Phonon::MediaSource src(buf); med->setCurrentSource(src); // <-- This hangs return med; } Most of the time, the application hangs the second time the above gets called; med->setCurrentSource(src) never returns. When the hang occurs, there's no CPU load. Everything works fine if I instead save file.read(size) into a new QFile and pass its fileName() to setCurrentSource(). However, in both cases, file.read(size) contains the exact same data. Again: this only happens with the Xine backend. The GStreamer backend works fine. I've prepared a very small example application that will trigger the bug: http://foss.math.aegean.gr/~realnc/qt/phonon_bug.tar.gz The tarball includes a small data file from which the code will try to load the embedded WAV files from. Simply "qmake; make" and then run it. There's no GUI. Here is a full backtrace at the moment the code hangs: #0 0x000000300100b1fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x000000300747420b in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=<value optimized out>, time=<value optimized out>) at thread/qwaitcondition_unix.cpp:87 code = <value optimized out> #2 QWaitCondition::wait (this=<value optimized out>, mutex=<value optimized out>, time=<value optimized out>) at thread/qwaitcondition_unix.cpp:159 returnValue = <value optimized out> #3 0x00007ffff71a6de0 in Phonon::Xine::XineThread::newStream () at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/xine/xinethread.cpp:78 that = <value optimized out> locker = {{mtx = 0x7a36e1, val = 8009441}} #4 0x00007ffff71bc669 in MediaObject (this=0x7a6d90, parent=<value optimized out>) at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/xine/mediaobject.cpp:61 No locals. #5 0x00007ffff71c1886 in Phonon::Xine::Backend::createObject (this=<value optimized out>, c=<value optimized out>, parent= 0x7a67b0, args=<value optimized out>) at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/xine/backend.cpp:154 No locals. #6 0x000000301b63843f in Phonon::Factory::createMediaObject (parent=<value optimized out>) at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/phonon/factory.cpp:317 No locals. #7 0x000000301b624e16 in Phonon::MediaObjectPrivate::createBackendObject (this=<value optimized out>) at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/phonon/mediaobject.cpp:47 No locals. #8 0x000000301b625e7b in Phonon::MediaNodePrivate::backendObject (this=<value optimized out>) at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/phonon/medianode.cpp:63 No locals. #9 0x000000301b623907 in Phonon::MediaObject::setCurrentSource (this=<value optimized out>, newSource=<value optimized out>) at /var/tmp/portage/media-sound/phonon-4.3.80-r1/work/phonon-4.3.80/phonon/mediaobject.cpp:230 __PRETTY_FUNCTION__ = "void Phonon::MediaObject::setCurrentSource(const Phonon::MediaSource&)" #10 0x000000000040162c in getMedia (fname=..., pos=393350, size=76844) at main.cpp:18 file = {<QIODevice> = {<QObject> = {_vptr.QObject = 0x30078758b0, static staticMetaObject = {d = {superdata = 0x0, stringdata = 0x300760c140 "QObject", data = 0x300760c1e0, extradata = 0x300786e480}}, d_ptr = {d = 0x6d6180}, static staticQtMetaObject = {d = {superdata = 0x0, stringdata = 0x3007614dc0 "Qt", data = 0x30076183e0, extradata = 0x0}}}, static staticMetaObject = {d = {superdata = 0x300786e460, stringdata = 0x300761ce00 "QIODevice", data = 0x300761ce60, extradata = 0x0}}}, static staticMetaObject = {d = {superdata = 0x30078759c0, stringdata = 0x300761cd80 "QFile", data = 0x300761cda0, extradata = 0x0}}} med = 0x7a67b0 buf = 0x7a6760 src = {d = {d = 0x7a45b0}} #11 0x00000000004017ca in main (argc=1, argv=0x7fffffffdba8) at main.cpp:29 app = {<QCoreApplication> = {<QObject> = {_vptr.QObject = 0x301e61c090, static staticMetaObject = {d = {superdata = 0x0, stringdata = 0x300760c140 "QObject", data = 0x300760c1e0, extradata = 0x300786e480}}, d_ptr = {d = 0x605190}, static staticQtMetaObject = {d = {superdata = 0x0, stringdata = 0x3007614dc0 "Qt", data = 0x30076183e0, extradata = 0x0}}}, static staticMetaObject = {d = {superdata = 0x300786e460, stringdata = 0x300761df40 "QCoreApplication", data = 0x300761dfe0, extradata = 0x0}}, static self = 0x7fffffffda60}, static staticMetaObject = {d = {superdata = 0x3007876980, stringdata = 0x301e2297e0 "QApplication", data = 0x301e229a20, extradata = 0x0}}}
Created attachment 223863 [details] emerge --info
phonon-4.4.0 is now in portage, please test
(In reply to comment #2) > phonon-4.4.0 is now in portage, please test Nothing changed. Did you try to test? It only takes a minute if you're already using Xine.
(In reply to comment #3) > (In reply to comment #2) > > phonon-4.4.0 is now in portage, please test > > Nothing changed. > media-sound/phonon > Did you try to test? It only takes a minute if you're already using Xine. > Can you try with media-sound/phonon-4.4.1-r1? (kde 4.4.4 will be the next stable)
I'm already on 4.4.1-r1 and the issue is still there. Doesn't look like upstream considers this bug a priority :P Anyway, instead of being dependent on me to test whether it's fixed, you could always try the sample application in the first post :) It's very easy to run: tar -xzf phonon_bug.tar.gz cd phonon_bug qmake; make ./phonon_bug If you run the "phonon_bug" binary a couple of times and the program hangs at least once and doesn't return without needing CTRL+C, then the bug is still there. I don't know whether 4.4.2 fixes this (I opened a version bump bug for it); my guess is not, since it's not in the changelog.
(In reply to comment #5) > I'm already on 4.4.1-r1 and the issue is still there. Doesn't look like > upstream considers this bug a priority :P > > Anyway, instead of being dependent on me to test whether it's fixed, you could > always try the sample application in the first post :) It's very easy to run: > > tar -xzf phonon_bug.tar.gz > cd phonon_bug > qmake; make > ./phonon_bug > > If you run the "phonon_bug" binary a couple of times and the program hangs at > least once and doesn't return without needing CTRL+C, then the bug is still > there. > > I don't know whether 4.4.2 fixes this (I opened a version bump bug for it); my > guess is not, since it's not in the changelog. > ################################ peratu@fujitsu ~ $ tar xf phonon_bug.tar.gz peratu@fujitsu ~ $ cd phonon_bug peratu@fujitsu ~/phonon_bug $ qmake; make g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_PHONON_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/phonon -I/usr/include/qt4 -I/usr/include/qt4/phonon_compat -I. -o main.o main.cpp g++ -Wl,-rpath,/usr/lib64/qt4 -o phonon_bug main.o -L/usr/lib64/qt4 -lphonon -lQtGui -L/usr/lib64 -L/usr/lib64/qt4 -L/usr/X11R6/lib -lQtCore -lgthread-2.0 -lrt -lglib-2.0 -lpthread peratu@fujitsu ~/phonon_bug $ ./phonon_bug Trying to setCurrentSource()... OK. Trying to setCurrentSource()... ^C peratu@fujitsu ~/phonon_bug $ ./phonon_bug Trying to setCurrentSource()... OK. Trying to setCurrentSource()... ^C peratu@fujitsu ~/phonon_bug $ ############################# I needed to press CTRL+C to exit the program, both times.
@Nikos I can't reproduce with the phonon-vlc backend which is the default one in the gentoo packages, should I resolve this bug and leave it to upstream?
(In reply to comment #7) > @Nikos > I can't reproduce with the phonon-vlc backend which is the default one in the > gentoo packages, should I resolve this bug and leave it to upstream? Well, I don't know. It's still a bug in the Xine backend :-P Upstream doesn't seem to care, but that won't make the bug go away. I'm still affected since the VLC backend doesn't work nice for me (buggy seek in Ogg and FLAC files, sometimes doesn't play files to end but skips to the next track prematurely.) Only Xine does work perfectly here. But I don't care much about this bug anymore anyway. I filed it because I was using Phonon in my own project. Since I threw that away (mostly because of this bug) and switched to SDL, I don't care either way if this bug is closed or not :-)
ok, thanks for the explanation, i am CC'ed in the upstream bug