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.
Anybody interested in patching a few bugs? The most serious 3.5.12 bugs affecting me are limited to kdelibs/kdebase. I would backport the patches to 3.5.12 and rebuild to test.
Here is a short list of bugs that affect me.
293, Kde-config Incorrectly Creates a Profile Folder in the System root directory
385, Unmounted removable device icons do not appear on the desktop
387, Kicker/Panel Clock Font Display Looks Weird
388, KDESU Dialog Box Behavior
393, Incorrect kdesu Behavior When Opening Kate
394, Problems with DCOP After Using kdesu
427, NumLock light does not reflect actual state
I use kdesu a lot. Those bugs are especially hindering.
Please let me know. I'll test any patches immediately.
Thanks everybody for your devotion and work.
Darrell
One way to learn about Cmake is starting from scratch.
So I started with kdeadmin, it didn't look like to big a project.
Nothing like getting your feet wet by jumping in at the deep end. :-D
The trouble is the water is above my head. :-(
I have spent many hours on this one.
A pointer in the right direction would be appreciated.
[ 29%] Building CXX object ksysv/CMakeFiles/ksysv.dir/OldView.cpp.o
/home/castro/Work/trinity-build/trinity-kdeadmin/src/kdeadmin/ksysv/OldView.cpp:22:20:
fatal error: config.h: No such file or directory
compilation terminated.
make[2]: *** [ksysv/CMakeFiles/ksysv.dir/OldView.cpp.o] Error 1
make[1]: *** [ksysv/CMakeFiles/ksysv.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
[castro@castro2 trinity-kdeadmin]$
Castro.
Tim, Serghei,
I know you both are working hard, but would one of you please provide an estimated date when the porting to cmake will be complete for all Trinity packages?
Thanks.
Darrell
Hi all,
We will have a meeting on 19 April 2011. Raindate has been set for 20
April 2011.
Topic discussion is currently going on in Etherpad:
http://trinity.etherpad.trinitydesktop.org/19
Scheduling has started, so that people may be able to attend (advance notice).
There are 6 times available. Please mark your selection:
http://www.doodle.com/eivtcn5c3wndqt2u
--
later, Robert Xu
Hi serghei,
Hi all,
This is my second day of learning about cmake.
You may find these changes more to your acceptable than my first
attempt. :-)
See mods-kdebase.tar.bz2
Castro.
Hello,
tqtinterface build system was massively reworked.
Available options:
QT_VERSION=3
or
USE_QT3 - activate Qt3 support
--------------------
QT_VERSION=4
or
USE_QT4 - activate Qt4 support
--------------------
QT_PREFIX_DIR - the place where qt is installed
default: /usr
For Qt3, QT_VERSION inherits QTDIR, _if_ QTDIR environment variable is set.
--------------------
QT_INCLUDE_DIR - the place where qt headers are installed
default: ${QT_PREFIX_DIR}/include/qt${QT_VERSION}
--------------------
QT_LIBRARY_DIR - the place of qt libraries
default: ${QT_PREFIX_DIR}/lib${LIB_SUFFIX}
For Qt4, libQtGui.so presence is checked, if is not exists in
${QT_PREFIX_DIR}/lib${LIB_SUFFIX}, ${QT_PREFIX_DIR}/lib${LIB_SUFFIX}/qt4 is
checked as well
--------------------
QT_LIBRARIES - list of qt libraries required for linking
Default for Qt3 - qt-mt
Default for Qt4 - QtCore QtGui
--------------------
QT_BINARY_DIR - the place where qt tools are installed (moc and uic)
default: ${QT_PREFIX_DIR}/bin
--------------------
MOC_EXECUTABLE - absolute path to moc
default: ${QT_BINARY_DIR}/moc
--------------------
UIC_EXECUTABLE - absolute path to uic
default: ${QT_BINARY_DIR}/uic
--------------------
Note: PKGCONFIG_INSTALL_DIR is defaulted to /usr/lib${LIB_SUFFIX}/pkgconfig,
to avoid tqt detection problems.
Note: these options are available only for tqtinterface, the rest of packages
inherits it automatically from tqt (for example, you do not need to pass
argument QT_VERSION=3 to kdelibs' cmake).
--
Serghei