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 :)
please, stop this imprudence! Linux on Virtual Machine! use real! and the lest see, oh good!
downgrade glibc 2.13 to 2.10 or 2.11, its clarely these imprudence to run on virtual machine are memory coruption!
On Thu, Feb 24, 2011 at 6:23 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
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.
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 Feb 23, 2011, at 18:26, PICCORO McKAY Lenz mckaygerhard@gmail.com wrote:
please, stop this imprudence! Linux on Virtual Machine! use real! and the lest see, oh good!
downgrade glibc 2.13 to 2.10 or 2.11, its clarely these imprudence to run on virtual machine are memory coruption!
Hi, Please STOP top-posting. Thanks.
On 02/23/2011 05:26 PM, PICCORO McKAY Lenz wrote:
please, stop this imprudence! Linux on Virtual Machine! use real! and the lest see, oh good!
downgrade glibc 2.13 to 2.10 or 2.11, its clarely these imprudence to run on virtual machine are memory coruption!
OK - no more imprudence :)
The need to use VM is caused by current condition of Trinity CMake files that will not ignore existing KDE4/Qt4 or KDE3 includes or libraries requiring you to either setup a whole new clean install on an existing computer or build in a VM. So far building in the VM has worked *perfectly*.
I see limitation of the VM builds with this x86_64 memory problem. But to build for both x86_64 with the current CMake files, if you don't build in a VM, that means you have to setup 2 new clean Linux installs.
I don't mind doing it because I have boxes to spare. But the CMake files need to be updated to build on a system with existing KDE4/Qt4 or KDE3 installs so that you can build Trinity without needing to do separate clean installs to provide a clean build environment.
Other things I've learned is that building in a chroot is not a simple solution due to the multiple layers of dependencies needed by each successive package. The dependencies are normal, but maintaining the chroot environment becomes difficult very quickly as package No. 5, 6, 7, etc. are built and installed - at least on Arch with the Xen kernel chroot.
I've setup an i686 box dedicated to Trinity building and I'll do the same on another x86_64 box, but it would sure be much easier to build, if we found a way to tailor the Trinity CMake files to ignore the foreseeable conflicting includes and libraries present with existing KDE4/Qt4 and KDE3 installs :)
Calvin has dug up some interesting CMake variables that may be needed to do this:
/NODEFAULTLIB CMAKE_EXE_LINKER_FLAGS (probably many more...)
I know nothing about them, but if we can get the CMake files to just look at the libraries and includes provided by the Trinity: Qt3, tqtinterface, arts, kdelibs, kdebase, etc... files, then we could dispense with needing to create new installs or VMs to get Trinity to build...
I know where this sits in the timeline, but it may be worth a look to see how difficult a cleanup to fix the library and include issue would be :)
-
David C. Rankin -
PICCORO McKAY Lenz -
Robert Xu