From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104436 invoked by alias); 30 Oct 2017 14:23:40 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 104419 invoked by uid 89); 30 Oct 2017 14:23:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=multiples, neglect, hid, U*vehre X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yw0-f172.google.com Received: from mail-yw0-f172.google.com (HELO mail-yw0-f172.google.com) (209.85.161.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Oct 2017 14:23:38 +0000 Received: by mail-yw0-f172.google.com with SMTP id l32so11663776ywh.13; Mon, 30 Oct 2017 07:23:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2CP5frisr4pryaZLQ+ecqOVOqCnYiJbjMExrfkK7/xg=; b=BEtzUGOSbJwG9v7VHmgrCYhI6WQASOdvIzuiEfPUW2c+qwY6/eECKI0qyzQj5zWq/p EOcIyq9NfHY2lTS2MHkN1aOq+wccHOns6Qg8QGdj14C5sxF0rIqgjBrsccQu0pLbwis+ MS9E3BAzZ4zDNhjC4Dvj+mXYHqWopw+CsmQpK2DXd1Z9/FWSwhC1RVC0m3CRUjAx8xXM sqgBqTgM00NW5CpXSoTQjmZKNN6iJ1djZPo1rNSPFi1H1ipm1KvswdBb/XquoVoLuLZ2 UQ4BJDgEYe2gA1H89r9pyQtJ4i9x+rQecht2vzwnp/6+VhFD2EcgyVWrgJG/D5f6Jv3Z SnIg== X-Gm-Message-State: AMCzsaVGyk0zXEc+3lEZj0dHBUWqGR610i3uHtLlK69LM2kRPRqlHbQJ JzBIcCH6H19BS9utcu1kPVTcJWtxnEPBRY8JgPk= X-Google-Smtp-Source: ABhQp+Tx+SD0az5wJBTpo8IudGe3OaZkgIwl7IZe93RAoaY3VzO1C9QceF0gglzqXC8GJeOk5HGjZLaFuGCzkSMUdbE= X-Received: by 10.129.226.76 with SMTP id z12mr6239825ywl.80.1509373416473; Mon, 30 Oct 2017 07:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.199.4 with HTTP; Mon, 30 Oct 2017 07:23:35 -0700 (PDT) In-Reply-To: <20171030143933.176f61e1@vepi2> References: <20171030143933.176f61e1@vepi2> From: Paul Richard Thomas Date: Mon, 30 Oct 2017 14:23:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer To: Andre Vehreschild Cc: "fortran@gcc.gnu.org" , gcc-patches , liakhdi@ornl.gov Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00127.txt.bz2 Hi Andre, You didn't cause the bug. That was generated by neglect of the correct transfer of actual to formal in gfc_conv_procedure_call. Your _len check hid the bug :-) We presumably have been have been allocating random multiples of the space required when passing class objects to unlimited dummies. The bug only emerged in Dmitry's code because of the heavy use of allocated memory arising exactly from such usage. Quite simply the system could not allocate any more memory. Cheers and thanks for the OK. Paul On 30 October 2017 at 13:39, Andre Vehreschild wrote: > Hi Paul, > > whoopsie, I remember that I inserted the check for _len > 0 in allocate(). So > it was me causing the bug. Thanks that you found it. The patch looks good to > me. Thanks for the work. > > - Andre > > On Mon, 30 Oct 2017 12:20:20 +0000 > Paul Richard Thomas wrote: > >> Dear All, >> >> This bug took a silly amount of effort to diagnose but once done, the >> fix was obvious. >> >> The bug is triggered in this function from the reporter's source file >> gfc_graph.F90: >> >> function GraphIterAppendVertex(this,vertex) result(ierr) >> !Appends a new vertex to the graph. >> implicit none >> integer(INTD):: ierr !out: error code >> class(graph_iter_t), intent(inout):: this !inout: >> graph iterator >> class(graph_vertex_t), intent(in), target:: vertex !in: new vertex >> type(vert_link_refs_t):: vlr >> >> ierr=this%vert_it%append(vertex) !<===== right here! >> ....snip.... >> return >> end function GraphIterAppendVertex >> >> 'vertex' is being passed to a class(*) dummy. As you will see from the >> attached patch and the ChangeLog, 'vertex' was being cast as unlimited >> polymorphic and assigned to the passed actual argument. This left the >> _len field indeterminate since it is not present in normal (limited?) >> polymorphic objects. >> >> Further down the way, in stsubs.F90(clone_object) an allocation is >> being made using the unlimited version of 'vertex as a source. Since >> the size passed to malloc for an unlimited source is, for _len > 0, >> the value of the _len multiplied by the vtable _size, the amount of >> memory is also indeterminate and causes the operating system to flag a >> failed allocation, pretty much at random. >> >> The ChangeLog and the patch describe the fix sufficiently well as not >> to require further explanation. I will write a testcase that tests the >> tree dump for the _len field before committing the patch. >> >> Bootstraps and regtests on FC23/x86_64 - OK for 7- and 8-branches? >> >> If I do not receive any contrary comments, I will commit tonight. >> >> Regards >> >> Paul >> >> 2017-10-30 Paul Thomas >> >> PR fortran/80850 >> * trans_expr.c (gfc_conv_procedure_call): When passing a class >> argument to an unlimited polymorphic dummy, it is wrong to cast >> the passed expression as unlimited, unless it is unlimited. The >> correct way is to assign to each of the fields and set the _len >> field to zero. > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein