Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
On 02/21/2011 08:41 PM, David C. Rankin wrote:
On 02/21/2011 05:09 PM, PICCORO McKAY Lenz wrote:
uff i reading this http://lists.freedesktop.org/archives/xcb/2010-March/005818.html and seem like that!
any help fron anybody here!
I'll follow up there. I can't believe that an libxcb problem would still be around a year later. <snip>
Guys, The problem is glibc-2.13-4. I have about 5 Arch/Trinity Virtualbox VMs. On one I had not updated, I started Trinity x86_64 and there was NO kdesktop crash. I then proceeded to update the VM to the current Arch packages which included: [2011-02-22 11:13] Generating locales... [2011-02-22 11:13] en_US.UTF-8... done [2011-02-22 11:13] en_US.ISO-8859-1... done [2011-02-22 11:13] Generation complete. [2011-02-22 11:13] upgraded glibc (2.13-3 -> 2.13-4) <snip> [2011-02-22 11:17] upgraded kernel26 (2.6.37-6 -> 2.6.37.1-1) [2011-02-22 11:17] upgraded kernel26-headers (2.6.37-6 -> 2.6.37.1-1) <snip> [2011-02-22 11:18] upgraded trinity-kdelibs (1220926-1 -> 1222098-1) [2011-02-22 11:18] upgraded trinity-kdebase (1221507-1 -> 1221588-1) On next reboot/restart, I got the kdesktop.kcrash (attached). So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect No kdesktop,kcrash. It looks like this is a glibc issue, so I'll follow up (below) with Arch to make sure it looks like glibc and not a package issue. Thanks for your help. cc: arch-general Arch devs - Do you think this could be a packaging/patch issue with Arch, or do you think is going to be glibc itself? It looks like glibc to me, but I thought I'd ask first before going to the glibc folks. -- David C. Rankin, J.D.,P.E.
On Tue, Feb 22, 2011 at 11:41:12AM -0600, David C. Rankin wrote:
On next reboot/restart, I got the kdesktop.kcrash (attached). So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect No kdesktop,kcrash. It looks like this is a glibc issue, so I'll follow up (below) with Arch to make sure it looks like glibc and not a package issue. Thanks for your help.
cc: arch-general
Arch devs - Do you think this could be a packaging/patch issue with Arch, or do you think is going to be glibc itself? It looks like glibc to me, but I thought I'd ask first before going to the glibc folks.
Allan broke it! No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation. [1] https://bugs.archlinux.org/task/22656
On 02/22/2011 12:23 PM, Lukas Fleischer wrote:
Allan broke it!
No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation.
Thank you Lukas! -- David C. Rankin, J.D.,P.E.
On 02/22/2011 12:23 PM, Lukas Fleischer wrote:
No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation.
Oops, Sorry, I forgot to ask -- "Do we need to reopend the bug, or just let you guys look at it based on the email?" -- David C. Rankin, J.D.,P.E.
On 23/02/11 04:23, Lukas Fleischer wrote:
On Tue, Feb 22, 2011 at 11:41:12AM -0600, David C. Rankin wrote:
On next reboot/restart, I got the kdesktop.kcrash (attached). So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect No kdesktop,kcrash. It looks like this is a glibc issue, so I'll follow up (below) with Arch to make sure it looks like glibc and not a package issue. Thanks for your help.
cc: arch-general
Arch devs - Do you think this could be a packaging/patch issue with Arch, or do you think is going to be glibc itself? It looks like glibc to me, but I thought I'd ask first before going to the glibc folks.
Allan broke it!
No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation.
That patch has been in mainline glibc for a couple of days now and is running on Fedora, Gentoo, ... Allan
On 02/22/2011 05:07 PM, Allan McRae wrote:
On 23/02/11 04:23, Lukas Fleischer wrote:
On Tue, Feb 22, 2011 at 11:41:12AM -0600, David C. Rankin wrote:
On next reboot/restart, I got the kdesktop.kcrash (attached). So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect No kdesktop,kcrash. It looks like this is a glibc issue, so I'll follow up (below) with Arch to make sure it looks like glibc and not a package issue. Thanks for your help.
<snip>
No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation.
That patch has been in mainline glibc for a couple of days now and is running on Fedora, Gentoo, ...
Allan
Any ideas on the x86_64 kdesktop crash that happens with glibc 2.13-4 but is absent with 2.13-3? Any reason to try recompiling glibc without glibc-2.13-prelink.patch - or - will that just give me 2.13-3? -- David C. Rankin, J.D.,P.E.
On 23/02/11 10:13, David C. Rankin wrote:
On 02/22/2011 05:07 PM, Allan McRae wrote:
On 23/02/11 04:23, Lukas Fleischer wrote:
On Tue, Feb 22, 2011 at 11:41:12AM -0600, David C. Rankin wrote:
On next reboot/restart, I got the kdesktop.kcrash (attached). So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect No kdesktop,kcrash. It looks like this is a glibc issue, so I'll follow up (below) with Arch to make sure it looks like glibc and not a package issue. Thanks for your help.
<snip>
No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation.
That patch has been in mainline glibc for a couple of days now and is running on Fedora, Gentoo, ...
Allan
Any ideas on the x86_64 kdesktop crash that happens with glibc 2.13-4 but is absent with 2.13-3? Any reason to try recompiling glibc without glibc-2.13-prelink.patch - or - will that just give me 2.13-3?
That prelink patch is very, very unlikely to cause the issue. It was also the only change between 2.13-3 and 2.13-4... As I pointed out, there are other distros using that patch without reported issue and it is now in glibc mainline so nothing is obviously wrong with it. Also, I have had no other crash reports since this update... I just looked back through this thread and your backtraces are all over the place. First it was an issue with libxcb, and then on a different VM it is somewhere completely different. What is difference across your VMs that you get consistent crashes in one but not the other? Allan
On Tuesday, February 22, 2011 07:41:53 PM Allan McRae wrote:
That prelink patch is very, very unlikely to cause the issue. It was also the only change between 2.13-3 and 2.13-4... As I pointed out, there are other distros using that patch without reported issue and it is now in glibc mainline so nothing is obviously wrong with it. Also, I have had no other crash reports since this update...
Allan
KDE4/Kernel segfaults when I plug in a USB device ( Nook ) after I updated today. It Worked fine since last week befor I updated. pacman -Syu Updated this [2011-02-22 15:52] upgraded glibc (2.13-3 -> 2.13-4) [2011-02-22 15:52] upgraded aalib (1.4rc5-7 -> 1.4rc5-8) [2011-02-22 15:52] upgraded alsa-lib (1.0.23-2 -> 1.0.24.1-1) [2011-02-22 15:52] upgraded alsa-utils (1.0.23-3 -> 1.0.24.2-1) [2011-02-22 15:52] upgraded calibre (0.7.45-1 -> 0.7.46-1) [2011-02-22 15:52] upgraded curl (7.21.3-1 -> 7.21.4-2) [2011-02-22 15:53] upgraded kernel26 (2.6.37-6 -> 2.6.37.1-1) [2011-02-22 15:53] upgraded kernel26-headers (2.6.37-6 -> 2.6.37.1-1) [2011-02-22 15:53] upgraded lib32-glibc (2.13-3 -> 2.13-4) [2011-02-22 15:53] upgraded lib32-alsa-lib (1.0.23-4 -> 1.0.24.1-1) [2011-02-22 15:53] upgraded ppp (2.4.5-1 -> 2.4.5-2) [2011-02-22 15:53] upgraded redland (1.0.12-4 -> 1.0.12-5) [2011-02-22 15:53] upgraded sane (1.0.21-4 -> 1.0.22-1) [2011-02-22 15:53] upgraded wget (1.12-3 -> 1.12-5)
On 02/22/2011 06:41 PM, Allan McRae wrote:
That prelink patch is very, very unlikely to cause the issue. It was also the only change between 2.13-3 and 2.13-4... As I pointed out, there are other distros using that patch without reported issue and it is now in glibc mainline so nothing is obviously wrong with it. Also, I have had no other crash reports since this update...
I just looked back through this thread and your backtraces are all over the place. First it was an issue with libxcb, and then on a different VM it is somewhere completely different. What is difference across your VMs that you get consistent crashes in one but not the other?
Allan
The basic x86_64 Arch VMs are the SAME VM, just moved from one box to the other (one on my laptop copied from my backup server where it was originally installed). The packages are identical on the VMs except on the first I had rebuilt libxcb and glibc with options(!strip) and CFLAGS="$CFLAGS -g". I will rebuild Trinity and update both VMs and then give updated .kcrashes for each. If 2.13-3 works fine and 2.13-4 causes the crash, it just points to some unintended consequence in the update. I'll rebuild, update both and report back. But if Baho is also seeing something -- the plot thickens. -- David C. Rankin, J.D.,P.E.
On 02/23/2011 01:38 PM, David C. Rankin wrote:
On 02/22/2011 06:41 PM, Allan McRae wrote:
That prelink patch is very, very unlikely to cause the issue. It was also the only change between 2.13-3 and 2.13-4... As I pointed out, there are other distros using that patch without reported issue and it is now in glibc mainline so nothing is obviously wrong with it. Also, I have had no other crash reports since this update...
I just looked back through this thread and your backtraces are all over the place. First it was an issue with libxcb, and then on a different VM it is somewhere completely different. What is difference across your VMs that you get consistent crashes in one but not the other?
Allan
The basic x86_64 Arch VMs are the SAME VM, just moved from one box to the other (one on my laptop copied from my backup server where it was originally installed). The packages are identical on the VMs except on the first I had rebuilt libxcb and glibc with options(!strip) and CFLAGS="$CFLAGS -g".
I will rebuild Trinity and update both VMs and then give updated .kcrashes for each. If 2.13-3 works fine and 2.13-4 causes the crash, it just points to some unintended consequence in the update. I'll rebuild, update both and report back. But if Baho is also seeing something -- the plot thickens.
I have rebuilt libxcb with !strip and CFLAGS="$CFLAGS -g". I have rebuild glibc with !strip and CFLAGS="$CFLAGS -g" ...and... removed all the 'manual strip' calls from the bottom of the package() function. The kdesktop crash happens just as before, but now all the ? marks are gone from the backtrace. The new backtrace with full information is: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64-archangel/kdesktop+... before removing the 'manual strip' info from package() it was: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64-archangel/kdesktop+... This is with Virtualbox 3.2.10. So I upgraded to 4.0.4 to see if there was any change... There wasn't anything I noticed. Same kdesktop crash: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64-archangel/kdesktop+... 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?? Any help pointing me in the right direction would be greatly appreciated :) -- David C. Rankin, J.D.,P.E.
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. 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. Any other choices for a clean build environment that doesn't involve a VM or archroot -- other than dumping an existing install and starting fresh? -- David C. Rankin, J.D.,P.E.
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??)
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. The other option is to set-up a repo in your chroot with your currently built packages. That way the dependencies get pulled in as needed. There should be flags for that in makechrootpkg too.
Any other choices for a clean build environment that doesn't involve a VM or archroot -- other than dumping an existing install and starting fresh?
If this is virtualbox specific, I'd try qemu-kvm. Allan
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
-- David C. Rankin, J.D.,P.E.
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.
On 24.02.2011 19:10, David C. Rankin wrote:
<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]
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.
It's not a glibc issue - glibc is actually telling you there's an error somewhere in the trinity code. -- Wieland Hoffmann
On 02/24/2011 01:17 PM, Wieland Hoffmann wrote:
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. It's not a glibc issue - glibc is actually telling you there's an error somewhere in the trinity code.
OK, That's good info, but why then does Fluxbox exhibit the same pixelation desktop crash when an xterm is launched? I can start fluxbox and I can look at the menus (change config settings in the menu), but as soon as I launch an app, the desktop does the same checkerboard wrap. I have no doubt that there are bugs in the Trinity code, but regardless, it shouldn't effect fluxbox. When running flux, I didn't get a backtrace dumped to the console running startx, but I had to click in the blind to shut it down after the screen went nuts. Hopefully this isn't one of those 'coincidences' where there are 2 bugs. (1 in Trinity and another in X effecting both Trinity and Fluxbox) What has me wondering is -- this is a brand new Arch install with nothing but base, base-devel, xorg and fluxbox on it (plus the Trinity I built). No new hardware (same laptop I run Arch on all the time). I'll try downgrading xorg and trying again and let you know how that goes. Let me know if you have any other thoughts. Thanks. -- David C. Rankin, J.D., P.E.
On 02/24/2011 06:38 PM, David C. Rankin wrote:
OK,
That's good info, but why then does Fluxbox exhibit the same pixelation desktop crash when an xterm is launched?
I can start fluxbox and I can look at the menus (change config settings in the menu), but as soon as I launch an app, the desktop does the same checkerboard wrap.
I have no doubt that there are bugs in the Trinity code, but regardless, it shouldn't effect fluxbox.
Wow, This is bizarre. The screen pixelated in kdemod3 (old standard version). I couldn't see a thing. I typed alt+f2 "ksnapshot" to grab a screenshot and while the screenshot did capture part of the screen pixelation on the right hand side, it looks a whole lot better than the screen did when I took the shot. I don't know whether this is X, glibc, libxcb or what, but if you look at the screenshot, you will notice that the kate document list (kate is on the left) has been repeated on the right side pixelated. You can also see this has wrapped 'over' thunderbird on the right side of the screen. This behaves like an old monitor timing issue, but I have experienced it on multiple boxes. Here is the screenshot for what it's worth. I'll have more time to look at this issue tomorrow. [222k] http://www.3111skyline.com/dl/dt/trinity/ss/screen-pixeled.jpg I can't explain why most of the screen looks right. It was a holy mess when I took the screenshot. -- David C. Rankin, J.D.,P.E.
On Thu, 24 Feb 2011 11:38:42 +1000 Allan McRae wrote:
If this is virtualbox specific, I'd try qemu-kvm.
If you want to do this than this can save your time: http://blog.bodhizazen.net/linux/convert-virtualbox-vdi-to-kvm-qcow Personally i would use qed with the new qemu-kmv 0.14.0 instead of qcow. But the handling with virtualbox is easier so David see this only as an information and not as an suggestion. See you, Attila
On 02/22/2011 11:41 AM, David C. Rankin wrote:
<snip>
Guys,
The problem is glibc-2.13-4. I have about 5 Arch/Trinity Virtualbox VMs. On one I had not updated, I started Trinity x86_64 and there was NO kdesktop crash. I then proceeded to update the VM to the current Arch packages which included:
<snip>
cc: arch-general
Arch devs - Do you think this could be a packaging/patch issue with Arch, or do you think is going to be glibc itself? It looks like glibc to me, but I thought I'd ask first before going to the glibc folks.
We are homing in on the cause and a possible solution: <quote> glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation. [1] https://bugs.archlinux.org/task/22656 </quote> -- David C. Rankin, J.D.,P.E.
participants (6)
-
Allan McRae
-
Attila
-
Baho Utot
-
David C. Rankin
-
Lukas Fleischer
-
Wieland Hoffmann