From patchwork Sat Feb 20 14:13:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Weimer X-Patchwork-Id: 585624 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id DB819140B97 for ; Sun, 21 Feb 2016 01:13:14 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b=LOQX5lxT; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type; q=dns; s=default; b=qJMlg7hynmVQN9aPxp7/TFaXYXmjH TwbE/VA5NIOzEJDbuV3UkA75dapZm1n47xt9pa+tzw+p1DTmqkCGYQ01LMpT2xBu d/If2WnQV/7xV9ZYbg1dI/vanNy+Jm6n8cCDefYsK7EZf70YEHLKYTMLiJbVRlnM U+kWc2aGg8bMLs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type; s=default; bh=8Ihpi0W5ZMAGTkA0bqkMY94TEVw=; b=LOQ X5lxTP6+kYUkzJBLaC4yd6G3zziYSO2qHfUv6txzR9BccoIy4iIjM0SHrPEMgdlf zMRcwla5DHZb2xnpoDTpX8Kql3ooUEv9EE5ZfSPr/iXyyRH/F0JgHj12ensDzy5S 44oULEpeOKUgvCWZc+RL48GeTOrTMFLNlC+m+84w= Received: (qmail 76997 invoked by alias); 20 Feb 2016 14:13:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 76983 invoked by uid 89); 20 Feb 2016 14:13:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=leaks, kernels, ineffective, 2016-02-20 X-HELO: mx1.redhat.com To: GNU C Library From: Florian Weimer Subject: [PATCH] test-skeleton.c: Do not set RLIMIT_DATA [BZ #19648] Message-ID: <56C8746D.4080900@redhat.com> Date: Sat, 20 Feb 2016 15:13:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 With older kernels, it is mostly ineffective because it causes malloc to switch from sbrk to mmap (potentially invalidating malloc testing compared to what real appliations do). With newer kernels which have switched to enforcing RLIMIT_DATA for mmap as well, some test cases will fail in an unintended fashion because the limit which was set previously does not include room for all mmap mappings. Florian 2016-02-20 Florian Weimer [BZ #19648] * test-skeleton.c (main): Do not set RLIMIT_DATA. diff --git a/test-skeleton.c b/test-skeleton.c index a2d90a2..29bdc9c 100644 --- a/test-skeleton.c +++ b/test-skeleton.c @@ -429,23 +429,6 @@ main (int argc, char *argv[]) setrlimit (RLIMIT_CORE, &core_limit); #endif -#ifdef RLIMIT_DATA - /* Try to avoid eating all memory if a test leaks. */ - struct rlimit data_limit; - if (getrlimit (RLIMIT_DATA, &data_limit) == 0) - { - if (TEST_DATA_LIMIT == RLIM_INFINITY) - data_limit.rlim_cur = data_limit.rlim_max; - else if (data_limit.rlim_cur > (rlim_t) TEST_DATA_LIMIT) - data_limit.rlim_cur = MIN ((rlim_t) TEST_DATA_LIMIT, - data_limit.rlim_max); - if (setrlimit (RLIMIT_DATA, &data_limit) < 0) - printf ("setrlimit: RLIMIT_DATA: %m\n"); - } - else - printf ("getrlimit: RLIMIT_DATA: %m\n"); -#endif - /* We put the test process in its own pgrp so that if it bogusly generates any job control signals, they won't hit the whole build. */ if (setpgid (0, 0) != 0)