23 Feb
2011
23 Feb
'11
10:53 p.m.
On 02/23/2011 01:38 PM, David C. Rankin wrote:
On 02/22/2011 06:41 PM, Allan McRae wrote:
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.
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.
23 Feb
23 Feb
11:26 p.m.
New subject: [trinity-devel] Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
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(a)suddenlinkmail.com> wrote:
On 02/23/2011 01:38 PM, David C. Rankin wrote:
other
--
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
Cofundador de Venenux;
http://shutendouji.net
creador de massenkoh linux.
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 (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(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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
11:44 p.m.
New subject: [trinity-devel] Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
On Feb 23, 2011, at 18:26, PICCORO McKAY Lenz <mckaygerhard(a)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.
24 Feb
24 Feb
12:09 a.m.
New subject: [trinity-devel] Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
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, J.D.,P.E.
5069
days inactive
5070
days old
3 comments
3 participants
participants (3)
-
David C. Rankin -
PICCORO McKAY Lenz -
Robert Xu