stack_grow_into_huge allocates large chunks
on memory and do_child() will eventually fail with SIGSEGV.

If system is set up to dump core, it can take significant
time until this action is completed. For example if ABRT
runs on such system, kernel is blocked on pipe_write for
couple of minutes:
  # time ./obj64/stack_grow_into_huge
  Starting testcase "./obj64/stack_grow_into_huge", pid 24257
  PASS

  real    29m12.060s
  user    0m0.013s
  sys     4m41.744s

Sep  7 06:56:54 ibm-p720-01-lp3 abrt[24259]: Saved core dump of pid
24258 (/root/libhugetlbfs/tests/obj64/stack_grow_into_huge) to
/var/spool/abrt/ccpp-2012-09-07-06:27:42-24258 (1098439983104 bytes)

With patch:
  Starting testcase "./obj64/stack_grow_into_huge", pid 24384
  PASS

  real    0m0.206s
  user    0m0.013s
  sys     0m0.193s

Signed-off-by: Jan Stancek <jstan...@redhat.com>
---
 tests/stack_grow_into_huge.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/tests/stack_grow_into_huge.c b/tests/stack_grow_into_huge.c
index f2aff74..a380da0 100644
--- a/tests/stack_grow_into_huge.c
+++ b/tests/stack_grow_into_huge.c
@@ -56,7 +56,17 @@
 
 void do_child(void *stop_address)
 {
+       struct rlimit r;
        volatile int *x;
+
+       /* corefile from this process is not interesting and limiting
+        * its size can save a lot of time. '1' is a special value,
+        * that will also abort dumping via pipe, which by default
+        * sets limit to RLIM_INFINITY. */
+       r.rlim_cur = 1;
+       r.rlim_max = 1;
+       setrlimit(RLIMIT_CORE, &r);
+
        do {
                x = alloca(STACK_ALLOCATION_SIZE);
                *x = 1;
-- 
1.7.1


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to