On 11/30/2011 08:43 PM, Henrik Nordström wrote:
> tis 2011-11-29 klockan 16:02 +0000 skrev Gordan Bobic:
>
>> So could a broken program cause something else to crash, or is the
>> danger limited to the program that is running?
>
> For a broken program to cause something else to crash either
> a) the output of the broken program is used as input to the other
> program and contains error causing it to crash.
> b) the broken program causes an acute resource shortage (i.e. out of
> virtual memory) causing other programs running at the same time to crash
> c) it's actually the kernel that is broken
>
>> The reason I ask is
>> because I have also seen some weirdness where, for example, gcc would
>> get stuck in an infinite loop during compiling, typically bloating until
>> the OOM killer terminates it. It doesn't happen often, but I have seen
>> it more than once.
>
> We have seen a couple of those on ARMv7hl f15, related to optimization
> or debug information exploding in size. But those have always been 100%
> reproducible. And most often repeatable on i386 as well, not just as
> noticeable there due to larger memory& swap and Fedora build farm
> running on x86_64 kernels which gives almost full 4GB virtual address
> space to applications. (3GB max on 32-bit kernels, i.e. arm)
That's good to know.
I have been digging a little deeper and from what I can tell, it would
appear that I have an issue related to gcj on an SMP machine. It
segfaults. For example when rebuilding the gcc package, sometimes this
happens:
/bin/sh ./libtool --tag=GCJ --mode=compile
/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/./gcc/gcj
-B/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/armv5tel-redhat-linux-gnueabi/libjava/
-B/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/./gcc/
-B/usr/armv5tel-redhat-linux-gnueabi/bin/
-B/usr/armv5tel-redhat-linux-gnueabi/lib/ -isystem
/usr/armv5tel-redhat-linux-gnueabi/include -isystem
/usr/armv5tel-redhat-linux-gnueabi/sys-include -fclasspath=
-fbootclasspath=../../../libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -O2 -g -pipe -Wall -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -march=armv5te -c -o
gnu/java/security/hash.lo
-fsource-filename=/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/armv5tel-redhat-linux-gnueabi/libjava/classpath/lib/classes
-MT gnu/java/security/hash.lo -MD -MP -MF gnu/java/security/hash.deps
@gnu/java/security/hash.list
libtool: compile:
/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/./gcc/gcj
-B/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/armv5tel-redhat-linux-gnueabi/libjava/
-B/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/./gcc/
-B/usr/armv5tel-redhat-linux-gnueabi/bin/
-B/usr/armv5tel-redhat-linux-gnueabi/lib/ -isystem
/usr/armv5tel-redhat-linux-gnueabi/include -isystem
/usr/armv5tel-redhat-linux-gnueabi/sys-include -fclasspath=
-fbootclasspath=../../../libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -O2 -g -pipe -Wall -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -march=armv5te -c
-fsource-filename=/builddir/build/BUILD/gcc-4.4.5-20110214/obj-armv5tel-redhat-linux-gnueabi/armv5tel-redhat-linux-gnueabi/libjava/classpath/lib/classes
-MT gnu/java/security/hash.lo -MD -MP -MF gnu/java/security/hash.deps
@gnu/java/security/hash.list -fPIC -o gnu/java/security/.libs/hash.o
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Tiger.java:
In method 'gnu.java.security.hash.Tige
r.transform(byte[],int)':
In file included from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Sha512.java:277,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Sha384.java:275,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Sha256.java:248,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Sha160.java:239,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/RipeMD160.java:289,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/RipeMD128.java:255,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/MD5.java:369,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/MD4.java:336,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/MD2.java:255,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/IMessageDigest.java:0,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Haval.java:805,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/HashFactory.java:183,
from
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/BaseHash.java:158,
from <built-in>:17:
/builddir/build/BUILD/gcc-4.4.5-20110214/libjava/classpath/gnu/java/security/hash/Tiger.java:863:
internal compiler error: Segmentation fault
But, rerunning the libtool command above the second time succeeds.
Works fine on a non-SMP machine, though.
Because I'm building things in mock, it's a tad hard to debug as is.
I'll try to get a core dump and see whether that provides any useful
insights. I'll also try the same thing after booting the kernel with
nosmp just to cross-check, since that cured an identical problem when
building hsqldb, for example (at the expense of running on only one core).
Meanwhile - does anybody know of a bug like this that might have been fixed?
Gordan
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
