From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier Matz <olivier.matz@6wind.com>
Subject: Re: pthread_barrier_deadlock in -rc1
Date: Wed, 2 May 2018 12:08:37 +0200
Message-ID: <20180502100837.zxy2k2x2p5pgczj2@neon>
References: <20180403130439.11151-1-olivier.matz@6wind.com>
 <20180424144651.13145-1-olivier.matz@6wind.com>
 <b5d7aab1-25eb-0d0c-a01c-50356777cf9c@redhat.com>
 <4256B2F0-EF9D-4B22-AC1A-D440C002360A@6wind.com>
 <f25e9bb5-9a52-786f-55ed-577cf1b91fe6@intel.com>
 <39d5baf8-2bad-6df8-0419-a06c65d41475@redhat.com>
 <2d828aa1-482f-7f19-1909-c3ca4599c9b2@intel.com>
 <5e5611b7-e3dd-e0fa-157f-1749f46198c5@intel.com>
 <20180502095730.hcdgbqtfxtkfp5vd@neon>
 <1350d4e4-e4bc-716b-38ea-3e81e8cb09a6@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
 Maxime Coquelin <maxime.coquelin@redhat.com>, dev@dpdk.org,
 Thomas Monjalon <thomas@monjalon.net>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 8DAF5DD2
 for <dev@dpdk.org>; Wed,  2 May 2018 12:08:43 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <1350d4e4-e4bc-716b-38ea-3e81e8cb09a6@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, May 02, 2018 at 06:01:20PM +0800, Tan, Jianfeng wrote:
> Hi Olivier and Anatoly,
> 
> [...]
> 
> > > > Below patch can fix another strange sigsegv issue in my VM. Please check
> > > > if it works for you. I doubt it's use-after-free problem which could
> > > > lead to different issues in different env. Please have a try.
> > > > 
> > > > 
> > > > diff --git a/lib/librte_eal/common/eal_common_thread.c
> > > > b/lib/librte_eal/common/eal_common_thread.c
> > > > index de69452..d91b67d 100644
> > > > --- a/lib/librte_eal/common/eal_common_thread.c
> > > > +++ b/lib/librte_eal/common/eal_common_thread.c
> > > > @@ -205,6 +205,7 @@ rte_ctrl_thread_create(pthread_t *thread, const char
> > > > *name,
> > > >                   goto fail;
> > > > 
> > > >           pthread_barrier_wait(&params->configured);
> > > > +       pthread_barrier_destroy(&params->configured);
> > > >           free(params);
> > > Should destroy also be called in fail case?
> > Yes, and also pthread_barrier_wait().
> > 
> > I did a quick test simulating a failure of rte_thread_setname(), and
> > without the wait, the barrier in the child thread blocks forever.
> > 
> 
> v1 has been sent without seeing this email. You are right, I misunderstood
> it. Will send a v2 based on this result.
> 
> Thanks,
> Jianfeng

Thanks.

Not sure it should be in the same patch, however there is also
a memory leak here:

        ret = pthread_create(thread, attr, rte_thread_init, (void *)params);
        if (ret != 0)
                return ret;