tde-devels February 2011

devels@trinitydesktop.org

16 participants
43 discussions

Fwd: Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
by David C. Rankin 12 Apr '11

12 Apr '11

Tim, All, Below is a backtrace and links to the full backtrace I get in Trinity kdesktop. There may be more than 1 bug here, but it looks like at least part of it may be in the Trinity code. Let me know if there is something else you think may help isolate the issue. -------- Original Message -------- Subject: Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc] Date: Thu, 24 Feb 2011 12:10:41 -0600 From: David C. Rankin <drankinatty(a)suddenlinkmail.com> Reply-To: General Discussion about Arch Linux <arch-general(a)archlinux.org> Organization: Rankin Law Firm, PLLC To: General Discussion about Arch Linux <arch-general(a)archlinux.org> On 02/23/2011 08:37 PM, David C. Rankin wrote: > On 02/23/2011 07:38 PM, Allan McRae wrote: >> On 24/02/11 10:15, David C. Rankin wrote: >>> On 02/23/2011 04:53 PM, David C. Rankin wrote: >>>> I have no idea what the error means, but it looks like malloc is complaining >>>> about corruption? >>>> >>>> #8 0x00007f3550d27b96 in malloc_printerr (action=3, str=0x7f3550dd6a2e >>>> "malloc(): memory corruption", ptr=<value optimized out>) at malloc.c:6283 >>>> #9 0x00007f3550d2a4ad in _int_malloc (av=0x7f3551012ea0, bytes=16) at >>>> malloc.c:4396 >>>> #10 0x00007f3550d2c460 in __libc_malloc (bytes=16) at malloc.c:3660 >>>> >>>> I'll also follow up with the Trinity folks because I have just tried downgrading >>>> to glibc 2.13-3 and I'm still getting the error on x86_64. No issues with i686 >>>> though?? >>>> >>> >>> Hmm.. This is looking like it is a memory corruption in VMs with glibc> ~ 2.11. >>> I'll dump building in Virtualbox and setup a new x86_64 box for the purpose. If >>> you have any other thoughts/ideas on the glibc/VM issue, I'd welcome them. >> >> Never heard of that. Do you have a link? I was thinking that this was a >> treading issue further up the stack... (libxcb??) > > No link. One of the guys on the Trinity list mentioned the problem, and googling > turned up a related glibc bug fixed 1/14/2011 > > http://www.virtualbox.org/ticket/7981 > > I don't know why the internals of a VM would cause the memory corruption entry > in the backtrace (but then again.. I don't know enough about it to know :) > >> >>> What this seems to indicate is that you can no longer rely on building in a >>> clean VirtualBox Arch VM. This problem is more acute for large projects with >>> multiple layers of dependencies where an archroot proves difficult for managing >>> dependencies for packages later in the build order. >> >> I use makechrootpkg -r /root/of/chroot -- -i. That tells makepkg to install >> after building and the lack of -c means the chroot cleaning does not occur so >> those packages stay installed. >> > > I had set up an archroot with an internal repository under > <archroot>/root/chrepo. On i686 it would load the packages as needed. On x86_64 > it wasn't behaving correctly at all. (same pacman.conf, etc..) I had used > makechrootpkg -r /root/of/chroot -- -i to manually install packages but ran into > problems so I switched to Virtualbox which was working *perfectly* until I ran > into this glibc/libxcb issue. > > (Virtualbox still works perfectly for building and running Trinity, it's just > this issues that has me questioning if vbox is causing problems) > > I'm about to dump kde4 and kdemod3 from an old laptop drive I've got and test > the issue on a native x86_64 outside of a VM. I'll let you know how it goes. > > If I can get you anything else from the install that has the glibc or libxcb > issue, let me know and I'm happy to do it. > > BTW: I've tested the kdemod3 update based on Trinity 3.5.12 on both i686 and > x86_64 and they seem to run fine. > >> >> If this is virtualbox specific, I'd try qemu-kvm. >> >> Allan >> > > Allan, There is something to this glibc/libxcb issue. I have just dumped a prior arch install on my X86_64 laptop and did a fresh net-install. Nothing but xorg (and dependencies) on the box. I loaded the latest Trinity binaries - no kdesktop crash, and it ran fine from startx. But the X resolution was 1024x768 due to xf86-video-fbdev being the only driver on the box at the time.. After going through all the kcontrol settings I normally use, I exited the desktop to install xf86-video-ati. On restart of the desktop, the resolution looked great, the desktop looked great, the kde useful tips window was fine -- then I cliced the 'Close' button on the useful tips window and my display ripped into little pixels wrapping the display around itself at least 10 times (the staggered checkerboard pixelation) Clicking in the blind, I was able to log off and was greeted by a backtrace on the console window. I started X again with the output redirected into a file to catch the error. The basic error is: <snip> COP: unregister 'kaccess' X Error: BadWindow (invalid Window parameter) 3 Major opcode: 7 Minor opcode: 0 Resource id: 0x2000006 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 6 Minor opcode: 0 Resource id: 0x2000006 *** glibc detected *** kdesktop [kdeinit]: double free or corruption (!prev): 0x00000000019b4020 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71b96)[0x7fabc07e2b96] /lib/libc.so.6(cfree+0x6c)[0x7fabc07e796c] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN18KBackgroundManagerD0Ev+0x24)[0x7fabbac2fdfe] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktopD1Ev+0xe8)[0x7fabbac23ba8] /opt/trinity/lib/libkdeinit_kdesktop.so(kdemain+0xc27)[0x7fabbac04dff] /opt/trinity/lib/kde3/kdesktop.so(kdeinitmain+0x20)[0x7fabbae9c77c] kdesktop [kdeinit][0x408728] kdesktop [kdeinit][0x409f75] kdesktop [kdeinit][0x40a866] kdesktop [kdeinit](main+0xa64)[0x40c1c1] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fabc078fdcd] kdesktop [kdeinit][0x4064b9] ======= Memory map: ======== 00400000-00411000 r-xp 00000000 08:06 904841 /opt/trinity/bin/kdeinit 00611000-00612000 rw-p 00011000 08:06 904841 /opt/trinity/bin/kdeinit 018a1000-0200f000 rw-p 00000000 00:00 0 [heap] 7fabb4000000-7fabb4021000 rw-p 00000000 00:00 0 7fabb4021000-7fabb8000000 ---p 00000000 00:00 0 7fabb9847000-7fabb98b3000 r-xp 00000000 08:06 813482 /usr/lib/libmng.so.1.0.0 7fabb98b3000-7fabb9ab2000 ---p 0006c000 08:06 813482 /usr/lib/libmng.so.1.0.0 <snip> The full error is: http://www.3111skyline.com/dl/dt/trinity/arch/err/X/startx-messages.txt The corresponding Xorg.0.log: http://www.3111skyline.com/dl/dt/trinity/arch/err/X/startx-messages.txt No (EE). I have no idea what this error is. Something is going wrong somewhere on x86_64 with either glibc or libxcb. I don't know if the output from the startx command and its backtrace will help narrow this down, but it seems to be a generic X/glibc/libxcb issue. When using the fbdev video driver, there was *no corruption* at all. Then when I loaded the ati driver all heck broke loose. I don't know what Virtualbox relies on to create its virtual display driver, but this glibc/libxcb issue is present on both nvidia and ati based host computers. When the current build in the x86_64 laptop is done, I'll load fluxbox and see what it does on top of the ati driver, but I suspect it will be exactly the same. I saw this same display pixelation a week ago on a suse 11.3 box after the xorg files were updated. I had to downgrade the xorg files there to recover. The pixelation/display wrapping was exactly the same there. I'll follow up with the fluxbox results (expect the same), but in the mean time, if you have any suggestions of what additional information could help, let me know and I'll go chase it down. Thanks -- David C. Rankin, J.D., P.E.

3 2

Flash in Konqueror
by Ilya Chernykh 13 Mar '11

13 Mar '11

Please check if you can access this page in Konq and view the Flash content: http://ti.arc.nasa.gov/destination/iss/flash/index.html If not, please add this patch to the repository: https://api.opensuse.org/public/source/KDE:KDE3/kdebase3/nsplugin-Preferenc…

5 14

bugs.pearsoncomputing.net - DNS entry causing confirmation email to be rejected by postfix 'reject_unknown_client'
by David C. Rankin 03 Mar '11

03 Mar '11

Tim, I went to register for the bugzilla and found that the confirmation request from 74.84.118.181 was rejected by postfix because 74.84.118.181 does not provide a proper reverse lookup causing: smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, reject_unknown_client It is 'reject_unknown_client' causing the rejection. From: http://www.postfix.org/postconf.5.html the rejection is caused when: 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. I'm no postfix expert, but to let the confirmation through, I just removed 'reject_unknown_client'. If there have been people who don't get the confirmation emails, this may one reason why :) The actual postfix rejection was: Feb 28 16:22:21 nirvana postfix/smtpd[6858]: warning: 74.84.118.181: address not listed for hostname pearsoncomputing.net Feb 28 16:22:21 nirvana postfix/smtpd[6858]: connect from unknown[74.84.118.181] Feb 28 16:22:22 nirvana postfix/smtpd[6858]: NOQUEUE: reject: RCPT from unknown[74.84.118.181]: 450 4.7.1 Client host rejected: cannot find your hostname, [74.84.118.181]; from=<bugs(a)pearsoncomputing.net> to=<snip> proto=ESMTP helo=<vali.starlink.edu> Feb 28 16:22:22 nirvana postfix/smtpd[6858]: disconnect from unknown[74.84.118.181] Somebody smart with postfix and bind can probably tell you what the exact issue is. Just looking, I see a helo from vali.starlink.edu and the "warning: 74.84.118.181: address not listed for hostname pearsoncomputing.net" -- David C. Rankin, J.D.,P.E.

2 9

Trinity packages for Arch
by Albert Vaca 02 Mar '11

02 Mar '11

Hi guys! I've updated Chakra's kdemod3 packages to Trinity 3.5.12 and I would like it to be added to the list of distributions with prebuilt packages. This is the thread in the Arch forums about the project: https://bbs.archlinux.org/viewtopic.php?id=97612 Best regards, Albert Vaca

5 25

Re: [trinity-devel] ldebase - login manager default fonts and distro neutral Greeting
by Calvin Morrison 28 Feb '11

28 Feb '11

Of course! If it is a bug then it should be filed immediately. The point of the bug tracker is to keep things organized. This is a smaller issue so unless it is in the tracker it maybe overlooked. Definitely file that baby. Calvin Morrison

2 1

ldebase - login manager default fonts and distro neutral Greeting
by David C. Rankin 28 Feb '11

28 Feb '11

Next time somebody is in the code near the default settings for Login Manager, have a look at the font size and Greeting line. The current fonts are 22 pt for the Greeting, 10 pt for Failures, and 10 pt for General. I would propose 14, 10, 8. The current greeting welcomes you to Ubuntu. I would propose Trinity? I'll update the default proposals on the wiki as well -- David C. Rankin, J.D.,P.E.

7 11

last post for the Trinity weekend - applications status chart
by David C. Rankin 28 Feb '11

28 Feb '11

Whew, I'm done for the weekend :) Attached is a chart showing the current state of the applications/... cmake ports as well as the errors I encountered trying to build the ones with the old CMakeLists.txt files. (these are just notes I took working through the applications directory) The chart should be self-explanatory. If there is an 'x' in the CMake Port column, that just means a CMakeLists.txt file exists (not necessarily a Trinity CMakeLists.txt file). If there is a date under the Date column, then I was able to build it on Arch. The errors encountered in building are listed in the Error Description column. Ignore the last column. The openoffice calc file is here: http://www.3111skyline.com/dl/dt/trinity/arch/doc/app-cmake-port.ods It would be helpful to keep some type of running list on the status of the port effort. (it may already exist - dunno) Great job to all on Trinity. It's really looking good. -- David C. Rankin, J.D.,P.E.

1 0

Trinity Road Plan
by Darrell Anderson 28 Feb '11

28 Feb '11

Are there plans to start focusing and resolving issues reported in the bugzilla? If so, when (what is the road plan)? Thanks. Darrell

3 2

kgtk-qt3: kfile.h error can't find tqdir.h, (in tqt/tqdir.h) - howto fix?
by David C. Rankin 28 Feb '11

28 Feb '11

Guys, I'm trying to learn how to solve these include errors. At first glance, it looks like the build isn't accepting my: export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/opt/trinity/include The error I'm dealing with is: [ 7%] Building CXX object kdialogd3/CMakeFiles/kdialogd3.dir/kdialogd.o cd /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3 && /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fno-exceptions -fno-check-new -fno-common -O2 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/common -I/opt/trinity/include -I/opt/qt/include -o CMakeFiles/kdialogd3.dir/kdialogd.o -c /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.cpp In file included from /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.h:4:0, from /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.cpp:3: /opt/trinity/include/kfile.h:21:19: fatal error: tqdir.h: No such file or directory compilation terminated. I think the short answer is the cmake files have not been tailored to Trinity, but I'm trying to figure out how to do that. The chain of the error seems simple, /opt/trinity/include/kfile.h includes: #include <tqdir.h> which is in /opt/trinity/include/tqt, so in order for it to be seen as a standard <file.h> include instead of a "tqt/file.h" include, the Trinity cmake setup must do something to tell the compiler to look in /opt/trinity/include/tqt as a standard include directory. I thought that was what I was doing with CMAKE_INCLUDE_PATH=.... What else do we need to do in the cmake files? Thanks :) -- David C. Rankin, J.D.,P.E.

2 3

applications/kde-style-qtcurve builds but looks like old CMakeLists.txt
by David C. Rankin 27 Feb '11

27 Feb '11

Guys, Just an update. I was able to get applications/kde-style-qtcurve to build with the existing CMakeLists.txt, but as with gtk-qt-engine, it doesn't look like a normal Trinity cmake file. This brings the current Trinity packages building on Arch to: trinity-app-amarok-1222475-1-x86_64.pkg.tar.xz trinity-app-gtk-qt-engine-1222892-1.0-x86_64.pkg.tar.xz trinity-app-style-qtcurve-1182805-1-x86_64.pkg.tar.xz trinity-arts-1214641-1-x86_64.pkg.tar.xz trinity-kdebase-1222475-1-x86_64.pkg.tar.xz trinity-kdelibs-1222475-1-x86_64.pkg.tar.xz trinity-kdevelop-1222477-1-x86_64.pkg.tar.xz trinity-kdewebdev-1222551-1-x86_64.pkg.tar.xz trinity-pyqt3-3.18.1-9-x86_64.pkg.tar.xz trinity-qt3-3.3.8-20-x86_64.pkg.tar.xz trinity-tqtinterface-1222551-1-x86_64.pkg.tar.xz Let me know if there are additional modules that should build under cmake. I have been watching svn update and browsing through the applications directory to see what might build. We should keep a list of what is currently ported and should be working. That way we can concentrate building on the new packages to catch build errors. If I can get my hands on a complete list, I'll add it to the HowToBuild wiki page so we have a running list. Also, if we should not expect the apps with the older generic looking CMakeLists.txt to work properly, let me know and I'll hold off making the development packages available to Arch. Thanks. -- David C. Rankin, J.D.,P.E.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels February 2011