[kde-freebsd] k3b-kde4 1.68.0 alpha3 port

[Juergen Lock]

On Wed, Oct 28, 2009 at 08:14:57PM +1000, Dima Panov wrote:
> On Wednesday 28 October 2009 08:16:49 Juergen Lock wrote:
> > On Wed, Oct 21, 2009 at 05:55:30PM -0400, Jason E. Hale wrote:
> > > Attached is a port for the latest KDE4 version of K3B (1.68.0 alpha3):
> > > http://www.k3b.org/
> > > This is still labeled alpha, but may be useful for some users who wish to
> > > reduce the need for KDE3 libraries.  You may, however, safely have this
> > > port installed along side of the KDE3 version of K3B.
> > >
> > > I added support for sysutils/cdrkit, but I would not recommend it for
> > > users with DVD drives since sysutils/dvd+rw-tools requires
> > > sysutils/cdrtools which conflicts with cdrkit.
> > >
> > > I would appreciate any other feedback or suggestions.
> > 
> > Ok I now tried to test this here (8/amd64 checked out some time after RC1
> > on a 4-core phenomII) and I get all kinds of strange startup crashes most
> > of the time, only sometimes it manages to reach the gui, and then with
> > the mouse cursor stuck at the `busy' little clock most of the time.
> > One type of crash ends up in drkonqi (its a SIGSEGV:)
> > 
> > [New Thread 80a4c8700 (LWP 100646)]
> > [New Thread 808b021c0 (LWP 100585)]
> > [Switching to Thread 80a4c8700 (LWP 100646)]
> > 0x00000008061bb20c in __error () from /lib/libthr.so.3
> > #0  0x00000008061bb20c in __error () from /lib/libthr.so.3
> > #1  0x00000008061b9305 in pthread_cond_signal () from /lib/libthr.so.3
> > #2  0x0000000804f3fdd5 in thread_sleep ()
> >    from /usr/local/lib/qt4/libQtCore.so.4
> > #3  0x0000000804f3ff76 in QThread::sleep ()
> >    from /usr/local/lib/qt4/libQtCore.so.4
> > #4  0x0000000800aa0f8e in K3b::MediaCache::PollThread::run
> >  (this=0x80a460580) at
> >  /usr/home/nox/ports/sysutils/k3b-kde4/work/k3b-1.68.0/libk3b/tools/k3bmedi
> > acache.cpp:106 #5  0x0000000804f40968 in QThreadPrivate::start ()
> >    from /usr/local/lib/qt4/libQtCore.so.4
> > #6  0x00000008061b14b1 in pthread_getprio () from /lib/libthr.so.3
> > #7  0x0000000000000000 in ?? ()
> > 
> >  the others left k3b.core.s which I put the (longish) backtraces
> > of at:
> > 	http://people.freebsd.org/~nox/k3b-kde4-gdb/
> > 
> >  ...and now I just looked whats at  #0  0x00000008061bb20c in __error ():
> > 
> > 0x00000008061bb200 <__error+1920>:	mov    $0x1c6,%rax
> > 0x00000008061bb207 <__error+1927>:	mov    %rcx,%r10
> > 0x00000008061bb20a <__error+1930>:	syscall
> > 0x00000008061bb20c <__error+1932>:	retq
> > 
> >  seems to be the return from the _umtx_op syscall that went in the
> > boondocks there?
> > 
> >  Soo, does anyone know of qt4/kde4 threading bugs on amd64?  Or is
> > the bug in fact in k3b which this box just happens to be `fast enough'
> > for to trigger?
> 
> Use it on my laptop without any problems.
> 
> >uname -a
> FreeBSD Fluffy.Khv.RU 9.0-900002-CURRENT FreeBSD 9.0-900002-CURRENT #0: Sat Oct  3 
> 20:27:28 VLAST 2009     fluffy at Fluffy.Khv.RU:/usr/obj/usr/src/sys/Spot  amd64
> 
> QT 4.6.0.TP1/KDE 4.3.2

Ok I meanwhile found out (thanx to Andriy Gapon for the hint! :) that
these crashes only happen when I use ahci(4) (i.e. I have ahci_load="YES"
in /boot/loader.conf.)  Now how ahci can cause userland threading to get
messed up is a mystery to me...  (ncq?  tho I thought that only gets
used for disks not atapi devices live optical drives are...)  Or maybe
it still is timing related and ahci just causes drive probing/io to
complete faster?

 Btw, I got another crash sometimes after clicking `eject':

zsh triton8% work/k3b-1.68.0/src/k3b
K3bQProcess::QProcess(0x0)
K3bQProcess::QProcess(0x0)
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_file.so
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_file.so
kdeinit4: preparing to launch /usr/local/kde4/lib/kde4/kio_file.so
QSocketNotifier: Invalid socket 5 and type 'Read', disabling...
k3b: Fatal IO error: client killed
KCrash: Application 'k3b' crashing...
sock_file=/home/nox/.kde4/socket-triton8.kn-bremen.de/kdeinit4__0
kdeinit4: preparing to launch /usr/local/bin/drkonqi
kbuildsycoca running...

 (and drkonqi then says the backtrace is useless.)

 Thanx,
	Juergen