X-Scanned-BY: MIMEDefang 2.68 on 10.5.11.26 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 References: <5444FAF3.5050201@redhat.com> <20141020223401.D1B8D221C31A@rock.dv.isc.org> Message-ID: <5449083B.4050007@redhat.com> Content-Type: text/plain; charset=UTF-8 X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by bugs.isc.org (Postfix) with ESMTP id CA7A72D2004F for ; Thu, 23 Oct 2014 13:53:03 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.redhat.com", Issuer "DigiCert SHA2 Extended Validation Server CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id E910C349414 for ; Thu, 23 Oct 2014 13:53:01 +0000 (UTC) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDr0Hm001509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 09:53:01 -0400 Received: from [10.34.4.147] (unused-4-147.brq.redhat.com [10.34.4.147]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDqxcv017403 for ; Thu, 23 Oct 2014 09:53:00 -0400 Delivered-To: bind9-bugs@bugs.isc.org Subject: Re: [ISC-Bugs #37530] Race condition when accessing rbt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Date: Thu, 23 Oct 2014 15:52:59 +0200 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: bind9-bugs@isc.org Content-Transfer-Encoding: 7bit From: Tomas Hozza RT-Message-ID: Content-Length: 798 On 10/21/2014 12:34 AM, Mark Andrews via RT wrote: > > A lock shouldn't be necessary. Reference counting should prevent > this. > Thank you for your response. We suspect that the issue is caused by our bind-dyndb-ldap plugin that uses the DYNDB API (not yet merged). The plugin calls dns_view_flushcache() when reconfiguring global forwarders. However we don't call it in section secured by isc_task_beginexclusive() and isc_task_endexclusive(). So the references seems to be counted right, but other threads seems to be attaching to the DB while it is being freed. If you can confirm that this can cause issues (race conditions) I think it is OK to close this ticket. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com