I looked at ways the aux-cache could cause a segfault, and given the
file is mmap'd and has data offsets in it that are used as pointers
without being checked it is not hard to see how a corrupt file could
cause a segfault. The following patch makes the segfaults I was able
to think of and create
On Sun, Mar 01, 2015 at 10:22:05PM +0100, Niels Thykier wrote:
> Excellent, thanks.
>
> I am taking the liberty of adding the patch tag for this one. If
> nothing else, I would greatly appreciate having ldconfig not seg. fault. :)
That makes sense to me.
> Sounds like the aux-cache could do wit
On Sun, Mar 08, 2015 at 09:48:50PM +0100, Aurelien Jarno wrote:
> Thanks for your work, it's nice we have been able to understand the real
> issue.
Well I thing the best summary of the problem is that the aux-cache
handling code is awful and doesn't check anything before using the
incoming data as
Package: eglibc
Version: 2.13-38
When I try to build pixman (0.26.0-4) in my powerpc wheezy chroot,
the testsuite fails.
The failure usually looks like:
*** glibc detected *** /tmp/pixman-0.26.0/build/test/.libs/lt-scaling-test:
corrupted double-linked list: 0x10068e80 ***
=== Backtrace: ==
If I disable use of altivec (VMX) in pixman, then the problem goes away.
Makes sense I suppose given it was in the VMX code that it was crashing.
Trying to use valgrind on pixman's failing tests shows lots of cases
of reading or writing beyong malloc'd blocks end, but it shows that for
running und
I am doing a test build of eglibc with commit
7e2fca8dd22e3bd932581d6479b0c552deff00b6 applied to see if it helps.
The commit is:
commit 7e2fca8dd22e3bd932581d6479b0c552deff00b6
Author: Alan Modra
Date: Tue Sep 25 16:30:06 2012 -0500
Fix bugs in powerpc pthread_once.
Ref gcc.
So that glibc patch didn't help.
So far all that works is turning off vmx support, or upgrading to a newer
glibc, but that may just be a timing change. Running with efence takes a
long time, but makes the problem go away and hence detects nothing, making
me again think that is a timing issue. It
So I have tried some more attempts.
If I disable vmx use in pixman, the crashes go away.
If I disable use of openMP in pixman, the crashes go away.
If I run on a power6 rather than power7, the crashes go away.
If I use strace, the crashes go away.
If I use gdb, the crashes go away.
If I install li
On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
> in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> being a notable exception) which means it's vulnerable to spectre and
> meltdown attacks, whereas 32-bit ARM is exclusively in-order. if you
> want t
On Fri, Jun 29, 2018 at 06:29:48PM +0200, Geert Uytterhoeven wrote:
> Are you sure you're not interchanging A8 and A9, cfr. Linux kernel commit
> e388b80288aade31 ("ARM: spectre-v2: add Cortex A8 and A15 validation of the
> IBE bit")?
Yes. That is the main reason the A9 is faster than the A8 at t
On Sat, Feb 15, 2020 at 04:35:20PM +0200, Grisha Grybyniuk wrote:
> Here it is
Anything in /etc/apt/sources.list.d/ ?
Also if you install and run apt-show-versions, you can filter out the
'uptodate' lines and see what packages it things are either from unknown
sources or too new.
--
Len Sorense
11 matches
Mail list logo
