From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7322 invoked by alias); 22 Jul 2008 20:18:33 -0000 Received: (qmail 7312 invoked by uid 22791); 22 Jul 2008 20:18:33 -0000 X-Spam-Check-By: sourceware.org Received: from exprod6og115.obsmtp.com (HELO exprod6og115.obsmtp.com) (64.18.1.35) by sourceware.org (qpsmtpd/0.31) with SMTP; Tue, 22 Jul 2008 20:18:13 +0000 Received: from source ([63.169.143.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP; Tue, 22 Jul 2008 13:18:05 PDT Received: from [192.168.48.108] (minint-coqjh0 [192.168.48.108] (may be forged)) (authenticated bits=0) by pine.yedev.com (8.12.8p2-20031203/8.12.6) with ESMTP id m6MKI5DE022149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 22 Jul 2008 13:18:05 -0700 (PDT) Message-ID: <4886407C.3050805@ybad.com> Date: Wed, 23 Jul 2008 00:46:00 -0000 From: Ted Phares User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: duane-gcc-help@duaneellis.com CC: gcc-help@gcc.gnu.org Subject: Re: malloc always returns null References: <48826281.1090109@duaneellis.com> In-Reply-To: <48826281.1090109@duaneellis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-07/txt/msg00253.txt.bz2 > NEWLIB requires the underlying function: "_sbrk" - in syscalls, In "OS" > type environment, SBRK would call the operating system requesting more > memory. > > In an embedded system using NEWLIB - the SBRK function has (a) a pointer > to the current end of the heap, it sort of works like this: > Newlib impliments it this way: (newlib source, libgloss, arm, syscalls.c) > > You want to set a break point at _sbrk - and step through the code. > Examine the addresses of variables as you do this. Thank you, Duane. You hit the nail on the head: sbrk()'s check for stack-heap collision was failing, because the user stack area happened to be set up ahead of the heap area in my memory map. I set up the more conventional arrangement where the heap & stack grow toward each other, and now malloc() is working. Thanks again, -ted