theres a related topic in glibc bugtraker, that can be help:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=12432

as show, seems are only on 64 bit .. umm the old thread about VirtualMachines its on 64Bit related?

On Wed, Apr 13, 2011 at 9:04 AM, Timothy Pearson < kb9vqf@pearsoncomputing.net> 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:

http://www.3111skyline.com/dl/dt/trinity/err/newqt3/xsession-error-new-qt3.t...

...

http://www.3111skyline.com/dl/dt/trinity/err/newqt3/new-qt3-no-work-file-lis...

...

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:

http://www.3111skyline.com/dl/dt/trinity/err/newqt3/PKGBUILD-qt3-trinity

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/libc.so.6(+0x71b96)[0x7fed6bd43b96] /lib/libc.so.6(cfree+0x6c)[0x7fed6bd4896c] /usr/lib/libxcb.so.1(+0x9b64)[0x7fed68288b64] /usr/lib/libxcb.so.1(xcb_wait_for_reply+0x124)[0x7fed682891c4] /usr/lib/libX11.so.6(_XReply+0x10d)[0x7fed6c597b3d] /usr/lib/libX11.so.6(XInternAtom+0xa4)[0x7fed6c581744]

/opt/trinity/lib/libkdeinit_kdesktop.so(_ZN18KBackgroundManagerC1EP7QWidgetP10KWinModule+0x4e6)[0x7fed661bd516]

...

/opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktop8initRootEv+0x430)[0x7fed661add80]

...

/opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktopC1Ebb+0x4b3)[0x7fed661b2d23]

...

/opt/trinity/lib/libkdeinit_kdesktop.so(kdemain+0x6b4)[0x7fed661947f4] kdesktop [kdeinit][0x408728] kdesktop [kdeinit][0x409f75] kdesktop [kdeinit][0x40a866] kdesktop [kdeinit](main+0xa64)[0x40c1c1] /lib/libc.so.6(__libc_start_main+0xfd)[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: libqt-mt.so.3: 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: libqt-mt.so.3: cannot open shared object file: No such file or directory" is self explanatory. However, if you check the file list link above, libqt-mt.so.3 is there:

07:36 alchemy:~/tmp> grep libqt-mt.so.3 new-qt3-no-work-file-list.txt /opt/qt/lib/libqt-mt.so.3 /opt/qt/lib/libqt-mt.so.3.3 /opt/qt/lib/libqt-mt.so.3.3.8

So, why is this file not being found? I don't know what is causing this, so I'm punting to the smart folks for help. I'll have a bit more time to dig into this this weekend, but if you have any thoughts, I would appreciate any help you can give to shorten the dig :)

-- David C. Rankin, J.D.,P.E.

Does this occur with SVN HEAD or just with 3.5.12?

There is a glibc issue that I had to work around recently; if you are working with 3.5.12 then I will send a link to the patch that fixes the problem.

Tim

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On Thursday 14 April 2011 12:45:40 pm David C. Rankin wrote:

On 04/13/2011 08:38 PM, Baho Utot wrote:

...

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.

I'll check this out after work today. Thanks!

Looking at it, the link is gone - I didn't delete it, must be something that happened with the latest kernel update and reboot?

I did, I used my rsync script which had --delete option. So it deleted everything that wasn't in the source directory when I updated the server. Opps

You have write permission to:

/srv/http/dl/dt/trinity/arch/dev/baho/ or /srv/http/dl/dt/trinity/arch

I have forgotten how we had it linked. When I first looked at /srv/http/dl/dt/trinity/arch/dev/baho it was owned by 1070:baho, so it looks like there was some UID mixup and the link probably disappeared on reboot since /srv and /home are on different partitions.

How do you want me to set it back up for you? Let me know if you have a preference, otherwise, I'll think through this tonight. IIRC, you just uploaded to /home/baho and it was linked to /srv/http/dl/dt/trinity/arch/dev/baho.

(I'm getting old... :)

Not as old as I am, see above ;)

The best way would be able to rsync directly into the directory that the web server serves ( I can't say that again ). So I tried my rsync script to place the files in/to /srv/http/dl/dt/trinity/arch/dev/baho/ and it worked so all is well.

I then went to http://www.3111skyline.com/dl/dt/trinity/arch/dev/baho/ and that worked so I think we are good.

Thanks

After the two large update to trinity svn of yesterday and today I now have a build problem with kdepim.. so I am working on that currently.

I also have trouble with kdevelop and gtk-qt-engine.

Currently I am only working the i686 side. When TDE gets to the point where the cmake port is complete and I have a mostly usable desktop ie kmail working good, wallet etc, I'll go for the x86_64.