From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21689 invoked by alias); 3 Mar 2006 22:01:22 -0000 Received: (qmail 21679 invoked by uid 48); 3 Mar 2006 22:01:19 -0000 Date: Fri, 03 Mar 2006 22:01:00 -0000 Message-ID: <20060303220119.21678.qmail@sourceware.org> From: "rsa at us dot ibm dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20040610193839.214.dlstevens@us.ibm.com> References: <20040610193839.214.dlstevens@us.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/214] sbrk() doesn't detect brk() failures. Malloc doesn't handle sbrk() failures X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00024.txt.bz2 List-Id: ------- Additional Comments From rsa at us dot ibm dot com 2006-03-03 22:01 ------- Created an attachment (id=901) --> (http://sourceware.org/bugzilla/attachment.cgi?id=901&action=view) testcase to demonstrate setrlimit() and sbrk() This source file provides a testcase. It basically sets the rlimit and then incrementally increases the data segment size with sbrk() until an error is returned. This happens to be when the data segment exceeds the hard limit of 1 page. Compile with: gcc -o glibc214 glibc214.c -DSBRK_EARLYSBRK setrlimit() must be preceeded by an initial call to sbrk() or subsequent sbrk() calls will fail. That is what the flag demonstrates; take it out and the test will fail very quickly. I tested this on powerpc32, powerpc64, and an i486 and didn't experience the problem that the bug addresses. gcc glibc kernel powerpc32 4.1.0 20060130 2.3.90 2.6.5-7.244-pseries64 powerpc64 4.1.0 20060130 2.3.90 2.6.5-7.244-pseries64 i486 4.0.3 20051201 2.3.5 2.6.12-1-k7 -- http://sourceware.org/bugzilla/show_bug.cgi?id=214 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.