Message: previous - next
Month: April 2011

Re: [trinity-devel] New Qt3 xsession crash on x86_64 - need collective wisdom :)

From: Baho Utot <baho-utot@...>
Date: Wed, 13 Apr 2011 21:38:01 -0400
On 04/13/2011 08:39 AM, David C. Rankin wrote:
> Baho, All,
>   I was working with the new Qt3 build on x86_64 and I ran into an 
> xsession crash that I need help identifying the cause.  I have put the 
> .xsession-error, trinity-qt3 file list up at:
>   I have reinstalled an older build of Qt3 and it works fine, so there 
> is something in the new build. The PKGBUILD is modeled after the one 
> you are using, but I have enabled the doc and examples. I have put the 
> PKGBUILD up here:
>   Looking at the xsession-error file, the following jump out at:
> DCOP: register 'anonymous-1000' -> number of clients is now 4
> DCOP:  'anonymous-1000' now known as 'kwin'
> kdeinit: Got EXEC_NEW 'kdesktop' from launcher.
> DCOP: register 'kdesktop' -> number of clients is now 5
> DCOP: register 'anonymous-1001' -> number of clients is now 6
> DCOP: register 'anonymous-1002' -> number of clients is now 7
> DCOP: unregister 'anonymous-1002'
> *** glibc detected *** kdesktop [kdeinit]: free(): invalid next size 
> (fast): 0x00000000008dda20 ***
> ======= Backtrace: =========
> /lib/[0x7fed6bd43b96]
> /lib/[0x7fed6bd4896c]
> /usr/lib/[0x7fed68288b64]
> /usr/lib/[0x7fed682891c4]
> /usr/lib/[0x7fed6c597b3d]
> /usr/lib/[0x7fed6c581744]
> /opt/trinity/lib/[0x7fed661bd516] 
> /opt/trinity/lib/[0x7fed661add80] 
> /opt/trinity/lib/[0x7fed661b2d23] 
> /opt/trinity/lib/[0x7fed661947f4]
> kdesktop [kdeinit][0x408728]
> kdesktop [kdeinit][0x409f75]
> kdesktop [kdeinit][0x40a866]
> kdesktop [kdeinit](main+0xa64)[0x40c1c1]
> /lib/[0x7fed6bcf0dcd]
> kdesktop [kdeinit][0x4064b9]
> ======= Memory map: ========
> <snip>
> DCOP aborting (delayed) call from 'anonymous-1001' to 'kdesktop'
> DCOP: unregister 'kdesktop'
> DCOP: unregister 'anonymous-1001'
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = kdesktop path = <unknown> pid = 1002
> kdeinit: Got EXEC_NEW 'drkonqi' from socket.
> kdeinit: PID 1001 terminated.
> kdeinit: Got EXEC_NEW 'kicker' from launcher.
> Could not load library! Trying exec....
> kdeinit: PID 1003 terminated.
> <snip>
> dcop: error while loading shared libraries: cannot open 
> shared object file: No such file or directory
> [startkde] Shutting down Trinity...
> kdeinit: terminate KDE.
> klauncher: Exiting on signal 1
> DCOP: unregister 'anonymous-14951'
> DCOP: unregister 'khotkeys'
> DCOP: unregister 'kded'
> DCOP: unregister 'anonymous-14950'
> DCOP: unregister 'klauncher'
> DCOPServer : slotShutdown() -> waiting for clients to disconnect.
> DCOPServer : slotExit() -> exit.
> [startkde] Running Trinity shutdown scripts...
> [startkde] Trinity shutdown complete.
>   I can't explain the first 2 error blocks, but the "dcop: error while 
> loading shared libraries: cannot open shared object 
> file: No such file or directory" is self explanatory. However, if you 
> check the file list link above, is there:
> 07:36 alchemy:~/tmp> grep new-qt3-no-work-file-list.txt
> /opt/qt/lib/
> /opt/qt/lib/
> /opt/qt/lib/
>   So, why is this file not being found? 

The path for the linker is not correct.

What is in /etc/ and /etc/

The dynamic link loader can not find the file you need an entry into one 
of those files/directory with /usr/qt/lib
You can look at /etc/trinity-kdelibs.conf as an example.

It could also be that the dynamic link loader is looking to /opt/qt/lib64

Do you have a/anything in /opt/qt/lib64?

This is what this part of the qt PKGBUILD is for.  It fixes up the 
libraries on 64 bit machines.
You could try adding that back in.  I took that out because I am only on 
i686 at the moment,  I havn't got "aroundtoit" installing a clean x86_64 
arch install.  I will at some time, as I just didn't want to fight the 
battle on both platforms at once.  When I get TDE to run on i686 (most 
things working) I go for the x86_64.

#   [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" 
#   [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" 
#   [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" 
#   [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" 
#   [ "$CARCH" = "x86_64" ] && sed -i "s|/opt/qt/lib64|/opt/qt/lib|g" 

This is one of the reasons I wanted to put qt3 back into /usr. I don't 
have to mess to much with the library paths.
Qt4 does own some files that has the same name as qt3 that's why the 
file error(s) occured when qt3 was placed in  /usr.
So I bumped it to /ust/qt3.  When TDE is fully ported to QT4 this will 
be a mute point as qt3 get binned.
Trinity runs just fine when everthing is compiled to live in /usr.

Also you can kill off this in your PKGBUILD

         -docdir ${_prefix}/share/doc/qt \
         -headerdir ${_prefix}/include/qt \
         -plugindir ${_prefix}/lib/qt/plugins \
         -datadir ${_prefix}/share/qt \
         -translationdir ${_prefix}/share/qt/translations \

It is not needed.

Try the latest qt3 PKGBUILD in my devel directory on your server, Not 
the one accessible on the http server.

PS. the link from the devel directory to the web served directory is 
gone so I can't update what the http server has.
You will need to remake the symlink.