From issues-return-50395-archive-asf-public=cust-asf.ponee.io@drill.apache.org Mon Mar 5 22:03:03 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4B5F6180608 for ; Mon, 5 Mar 2018 22:03:03 +0100 (CET) Received: (qmail 44972 invoked by uid 500); 5 Mar 2018 21:03:02 -0000 Mailing-List: contact issues-help@drill.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@drill.apache.org Delivered-To: mailing list issues@drill.apache.org Received: (qmail 44963 invoked by uid 99); 5 Mar 2018 21:03:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Mar 2018 21:03:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id D6F77C0466 for ; Mon, 5 Mar 2018 21:03:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.511 X-Spam-Level: X-Spam-Status: No, score=-109.511 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id HmXABDznKayM for ; Mon, 5 Mar 2018 21:03:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id E005D5F3B9 for ; Mon, 5 Mar 2018 21:03:00 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 7C4EDE0112 for ; Mon, 5 Mar 2018 21:03:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 395882126E for ; Mon, 5 Mar 2018 21:03:00 +0000 (UTC) Date: Mon, 5 Mar 2018 21:03:00 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: issues@drill.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (DRILL-6125) PartitionSenderRootExec can leak memory because close method is not synchronized MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DRILL-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386763#comment-16386763 ] ASF GitHub Bot commented on DRILL-6125: --------------------------------------- Github user ilooner commented on a diff in the pull request: https://github.com/apache/drill/pull/1105#discussion_r172327106 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/partitionsender/PartitionSenderRootExec.java --- @@ -231,7 +231,7 @@ public boolean innerNext() { } @VisibleForTesting - protected void createPartitioner() throws SchemaChangeException { + protected synchronized void createPartitioner() throws SchemaChangeException { --- End diff -- Removed > PartitionSenderRootExec can leak memory because close method is not synchronized > -------------------------------------------------------------------------------- > > Key: DRILL-6125 > URL: https://issues.apache.org/jira/browse/DRILL-6125 > Project: Apache Drill > Issue Type: Bug > Affects Versions: 1.13.0 > Reporter: Timothy Farkas > Assignee: Timothy Farkas > Priority: Minor > Fix For: 1.13.0 > > > PartitionSenderRootExec creates a PartitionerDecorator and saves it in the *partitioner* field. The creation of the partitioner happens in the createPartitioner method. This method get's called by the main fragment thread. The partitioner field is accessed by the fragment thread during normal execution but it can also be accessed by the receivingFragmentFinished method which is a callback executed by the event processor thread. Because multiple threads can access the partitioner field synchronization is done on creation and on when receivingFragmentFinished. However, the close method can also be called by the event processor thread, and the close method does not synchronize before accessing the partitioner field. Since synchronization is not done the event processor thread may have an old reference to the partitioner when a query cancellation is done. Since it has an old reference the current partitioner can may not be cleared and a memory leak may occur. -- This message was sent by Atlassian JIRA (v7.6.3#76005)