From owner-freebsd-fortran@FreeBSD.ORG Fri Aug 23 10:20:18 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 AC3FD95C for ; Fri, 23 Aug 2013 10:20:18 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5A92BC2 for ; Fri, 23 Aug 2013 10:20:14 +0000 (UTC) Received: from mail-wi0-f180.google.com ([209.85.212.180]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKUhc3QP3tWrJHHlKUa7rlu3vXl6dzx85J@postini.com; Fri, 23 Aug 2013 10:20:18 UTC Received: by mail-wi0-f180.google.com with SMTP id l12so330981wiv.13 for ; Fri, 23 Aug 2013 03:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Rr2Lrnubaj/ZoqNaKCDCwuXXvsCfarGukxxsAur2eG3hX1PINuewng7FPKzsXtTGZ/ hwsP4oKlVy39Ew9oCXEwbZqHzwS/27K3yUr7DcawRAd2/dErWrODMVsYlgJ7/T0ZZXdC 5OT1gQ72RRTl/3X62nGk+hDb7f29ghGpo8ZxeVWz6kBmotbk/E382oRMOkxrXKOClgjY OlSufx3pFSvDVPOsRGT7G4ndRVsGOyHdnPsEliQykAM/A6InaTTkKVa16Nyx7W0kBbFo QXInSu9pJvN0Wl9uxqAeQBpx0YmpufcxTsRDPWtBt/rVuJXqmQUb/51mNJluKFk0/RDG /6gw== X-Gm-Message-State: ALoCoQmhguI9YixAKDcJrcRBB45EtPRTZLZYXSPcwNPVRUMkGMV25oE3LS/tBgDifS5nCHBOSC+ii4Jo0ydIJIpBmUbiVCYFmbRfkQVFRl8XR8Pql+ZiDsG40hht0wYFj6D8+r3+tKBbbxfHq9GLFbIQimCmGDiweg== X-Received: by 10.180.208.66 with SMTP id mc2mr1601777wic.39.1377253184204; Fri, 23 Aug 2013 03:19:44 -0700 (PDT) X-Received: by 10.180.208.66 with SMTP id mc2mr1601773wic.39.1377253184125; Fri, 23 Aug 2013 03:19:44 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id l7sm2758136wiw.4.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 03:19:43 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r7NAJf3M043240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 23 Aug 2013 11:19:41 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r7NAJfwr043239 for fortran@freebsd.org; Fri, 23 Aug 2013 11:19:41 +0100 (BST) (envelope-from mexas) Date: Fri, 23 Aug 2013 11:19:41 +0100 (BST) From: Anton Shterenlikht Message-Id: <201308231019.r7NAJfwr043239@mech-cluster241.men.bris.ac.uk> To: fortran@freebsd.org Subject: lazy memory allocation X-BeenThere: freebsd-fortran@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Fortran on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 10:20:18 -0000 From owner-freebsd-fortran@FreeBSD.ORG Fri Aug 23 10:26:10 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 48261B31 for ; Fri, 23 Aug 2013 10:26:10 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com [207.126.144.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99EFE2C0B for ; Fri, 23 Aug 2013 10:26:09 +0000 (UTC) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKUhc4urqPluDh9ZmvtYKJ9NEOzgV3ROH1@postini.com; Fri, 23 Aug 2013 10:26:09 UTC Received: by mail-wi0-f182.google.com with SMTP id hi8so379398wib.3 for ; Fri, 23 Aug 2013 03:26:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to; bh=807c8F9tjgunPOkR/3J0MEdQzNQdIuUtgVoEBg2w3Bg=; b=D8d6IG7Jy+k6PGSO1GU9qkX0oun67NC0byadOjo5DsllpoM++jYsvcTuw7W/bNZAE2 pxOockHBg0wWEhzyJFmO76BJSVuDD8rZhCyNo7S/Vdzr1/jc1uGQjmPJ6D1YXlet9uab cXQqewdbxKCHAjujYZe2yh1ZX7g1iEKEg7UJN9uvbDOBnxfvkWaW72o0f24qYGNAKWHZ E7kov54YQolOKttgBqHSFJkHdQHoOxF8gZ1PO4quub1xrndJpohvVQlTVFvoFth8bNvz nsy+ctP5uQnz/dqH+NFRHss6U5XFwyCAYVjLezWW5QYYhMdo7DXsSOudm0o4lNxSf/eB OTUg== X-Gm-Message-State: ALoCoQmgJFKhSJe+3P8SJYmmfdjUt3g+J10waT0ZOAEVRVn9qe3twjWdILIu4r6J7F7iFF7F7Ma09EQv1AmFUvrf6vTDQdpzxx2cTHENWVp5Ef1szH2rb5Wx3WvxIZlTLXN2B7aaUHi8tXg9EzZvJH7aeiHknICbnQ== X-Received: by 10.180.75.16 with SMTP id y16mr1593812wiv.59.1377253561996; Fri, 23 Aug 2013 03:26:01 -0700 (PDT) X-Received: by 10.180.75.16 with SMTP id y16mr1593810wiv.59.1377253561934; Fri, 23 Aug 2013 03:26:01 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id z2sm2774762wiv.11.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 03:26:01 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r7NAPwh3043267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 23 Aug 2013 11:25:58 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r7NAPwNH043266 for fortran@freebsd.org; Fri, 23 Aug 2013 11:25:58 +0100 (BST) (envelope-from mexas) Date: Fri, 23 Aug 2013 11:25:58 +0100 (BST) From: Anton Shterenlikht Message-Id: <201308231025.r7NAPwNH043266@mech-cluster241.men.bris.ac.uk> To: fortran@freebsd.org Subject: lazy memory allocation X-BeenThere: freebsd-fortran@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Fortran on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 10:26:10 -0000 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? Anton From owner-freebsd-fortran@FreeBSD.ORG Fri Aug 23 17:10:46 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 E83316DC for ; Fri, 23 Aug 2013 17:10:46 +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 AE6B02502 for ; Fri, 23 Aug 2013 17:10:46 +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 r7NHAg7l047702; Fri, 23 Aug 2013 10:10:42 -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 r7NHAgAP047701; Fri, 23 Aug 2013 10:10:42 -0700 (PDT) (envelope-from sgk) Date: Fri, 23 Aug 2013 10:10:42 -0700 From: Steve Kargl To: Anton Shterenlikht Subject: Re: lazy memory allocation Message-ID: <20130823171042.GA47588@troutmask.apl.washington.edu> References: <201308231025.r7NAPwNH043266@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201308231025.r7NAPwNH043266@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: Fri, 23 Aug 2013 17:10:47 -0000 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.) You can also add in STAT and ERRMSG after SOURCE to inspect whether allocation was successful. -- Steve From owner-freebsd-fortran@FreeBSD.ORG Sat Aug 24 20:36:33 2013 Return-Path: Delivered-To: fortran@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B857646D for ; Sat, 24 Aug 2013 20:36:33 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog118.obsmtp.com (eu1sys200aog118.obsmtp.com [207.126.144.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 109E321DC for ; Sat, 24 Aug 2013 20:36:32 +0000 (UTC) Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKUhkZLTleRPLXyDSVBDfe7iTzE+FajenG@postini.com; Sat, 24 Aug 2013 20:36:33 UTC Received: by mail-wg0-f41.google.com with SMTP id c11so2693046wgh.4 for ; Sat, 24 Aug 2013 13:35:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=c8WTyocoZrV6CUVG0yWpDBxkiPbyKHBKy07TC2NWnJQ=; b=AXW1ftGx+cEEzcYYw/Pxqb7gkkUi5Dir26nSYoYEKzbQYGtAhhfqnbMK8v6DgES7iC n8i2YLx+AeiB9VzRCGFQhBnONdt+jzrL7Bx3DRDWpCt43ansPW+F9HcxsUbnEHYkS2Uy pj2wf7vQ61+z6i1eJPVfjx7eQZpq2K85+ufpq0AiynoILZ/HF4FXOogrnz03uwM66oZb yNw36ObvriaEc+NhktLEdnCQSuM7kpdyLUjyfwau4VYnNsqcFkRfn4pBRvjNsuv8Tc3O tZezaJ94XAAFOsm2OCKBNzZlUCiSA+nWidYuFpQo1WxUKqvAisAXAnbygjGwhU3JSDOR e+0Q== X-Gm-Message-State: ALoCoQkLhseTrdYVzDTF0XjeLTrYxBP8DoHK9LBmrI29KvQL9FFKjwPfu6g7ojHpR+2eBNyXPXzL/zbiGPWrTY/cWShLGToRfJsAaamegqiz6xU1o2nvWZczIM9HQ50HSqRnmMd4rqOtnmXkoEqKsN/5mNoZ/LY/Cw== X-Received: by 10.180.160.203 with SMTP id xm11mr2392545wib.17.1377376556954; Sat, 24 Aug 2013 13:35:56 -0700 (PDT) X-Received: by 10.180.160.203 with SMTP id xm11mr2392540wib.17.1377376556887; Sat, 24 Aug 2013 13:35:56 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id jf9sm6658344wic.5.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 13:35:55 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r7OKZrKf059462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Aug 2013 21:35:53 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r7OKZrbU059461; Sat, 24 Aug 2013 21:35:53 +0100 (BST) (envelope-from mexas) Date: Sat, 24 Aug 2013 21:35:53 +0100 (BST) From: Anton Shterenlikht Message-Id: <201308242035.r7OKZrbU059461@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk, sgk@troutmask.apl.washington.edu Subject: Re: lazy memory allocation In-Reply-To: <20130823171042.GA47588@troutmask.apl.washington.edu> Cc: fortran@freebsd.org X-BeenThere: freebsd-fortran@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Fortran on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 20:36:33 -0000 >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 Anton 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