From owner-freebsd-fortran@FreeBSD.ORG Sat Aug 24 20:50:37 2013 Return-Path: Delivered-To: fortran@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8EE9E881 for ; Sat, 24 Aug 2013 20:50:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D7A2225F for ; Sat, 24 Aug 2013 20:50:37 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7OKoX1O055152; Sat, 24 Aug 2013 13:50:33 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7OKoXW6055151; Sat, 24 Aug 2013 13:50:33 -0700 (PDT) (envelope-from sgk) Date: Sat, 24 Aug 2013 13:50:33 -0700 From: Steve Kargl To: Anton Shterenlikht Subject: Re: lazy memory allocation Message-ID: <20130824205033.GA55140@troutmask.apl.washington.edu> References: <20130823171042.GA47588@troutmask.apl.washington.edu> <201308242035.r7OKZrbU059461@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201308242035.r7OKZrbU059461@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fortran@freebsd.org X-BeenThere: freebsd-fortran@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Fortran on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 20:50:37 -0000 On Sat, Aug 24, 2013 at 09:35:53PM +0100, Anton Shterenlikht wrote: > >From sgk@troutmask.apl.washington.edu Fri Aug 23 19:28:09 2013 > > > >On Fri, Aug 23, 2013 at 11:25:58AM +0100, Anton Shterenlikht wrote: > >> I've been burned by what's apparently called > >> "lazy memory allocation" on linux. > >> > >> My code calls a subroutine that allocates > >> a coarray. This routine exits fine, with > >> no error. However, when I tried to initialise > >> the coarray, I got segfault. On investigation > >> I discovered that the coarray was not in fact > >> allocated. In my particular case this was > >> because there was not enough memory. > >> > >> Anyway, I was later told that this is an > >> expected behaviour on linux, with its > >> "lazy memory allocation". > >> > >> I'm wondering if FreeBSD also uses > >> a lazy memory allocation, or we do it differently? > > > >man malloc. > > > >FreeBSD uses jemalloc, which allows one to tune the > >allocators behavior. I suspect, but have not tried > >to verify, that by default it uses lazy memory > >allocation. > > > >To avoid possible issues with lazy memory allocation, > >initialize the memory. > > > >real, allocatable :: a(:) > >allocate(a(10) :: source=0.) > > ok, thanks for this hint > > >You can also add in STAT and ERRMSG after SOURCE to > >inspect whether allocation was successful. > > That's the thing. I had it, like in > > integer :: errstat=0 > allocate(a(10),stat=errstat) > if (errstat .ne. 0) stop "some msg" > > And didn't get stopped, i.e. errstat was zero > on exit from ALLOCATE. The segfault happened on > > a = some_value > Yes, of course, that's the behavior expected with lazy allocation. The return status from malloc will indicate that memory has been allocated, but it isn't actaully allocated until its touched. That's why you need to do 'allocate(a(10) :: source=0.)'. This will touch the memory, and should fail on lazy memory allocators if memory isn't available. -- Steve