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)