From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101466 invoked by alias); 13 Dec 2018 15:51:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 101442 invoked by uid 89); 13 Dec 2018 15:51:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Dec 2018 15:51:42 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gXTH2-0002Ct-IB from Thomas_Schwinge@mentor.com ; Thu, 13 Dec 2018 07:51:40 -0800 Received: from hertz.schwinge.homeip.net (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 13 Dec 2018 15:51:37 +0000 From: Thomas Schwinge To: Chung-Lin Tang , Julian Brown CC: , , Jakub Jelinek Subject: Re: [PATCH 0/6, OpenACC, libgomp] Async re-work In-Reply-To: References: <432c2e58-7bf6-1f7e-457f-32813207b282@mentor.com> <20181206222246.1cceb504@squid.athome> <20181206222621.16ec00f0@squid.athome> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Thu, 13 Dec 2018 15:51:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-12/txt/msg00940.txt.bz2 Hi! On Thu, 13 Dec 2018 23:28:49 +0800, Chung-Lin Tang wrote: > On 2018/12/7 6:26 AM, Julian Brown wrote: > > On Thu, 6 Dec 2018 22:22:46 +0000 > > Julian Brown wrote: > >=20 > >> On Thu, 6 Dec 2018 21:42:14 +0100 > >> Thomas Schwinge wrote: > >> > >>> [...] > >>> ..., where the "Invalid read of size 8" happens, and which > >>> eventually would try to "free (tgt)" again, via > >>> libgomp/target.c:gomp_unmap_tgt: > >>> > >>> attribute_hidden void > >>> gomp_unmap_tgt (struct target_mem_desc *tgt) > >>> { > >>> /* Deallocate on target the tgt->tgt_start .. tgt->tgt_end > >>> region. */ if (tgt->tgt_end) > >>> gomp_free_device_memory (tgt->device_descr, tgt->to_free); > >>>=20=20=20=20=20=20 > >>> free (tgt->array); > >>> free (tgt); > >>> } > >>> > >>> Is the "free (tgt)" in libgomp/target.c:gomp_unmap_vars_async wrong, > >>> or something else? > >> > >> It might be worth trying this with the refcounting changes in the > >> attach/detach patch. Well, which exactly? > > ...oh, also make sure you have this patch in the series you're testing > > with: > >=20 > > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01973.html > >=20 > > else your "wait" will be ignored, IIUC. Thanks, and right, and yes, I got that one included. > just first asking if you tried Julian's patch during this time, and if so= did it do anything different? I did not test with all the attach/detach patches on top of this one here. That's too many changes at once. Gr=C3=BC=C3=9Fe Thomas