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.
