From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Subject: Re: pthread_barrier_deadlock in -rc1
Date: Wed, 2 May 2018 18:16:43 +0800
Message-ID: <8397cf2e-cb02-954a-3dbe-3be580767868@intel.com>
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>
 <20180502100837.zxy2k2x2p5pgczj2@neon>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
 Maxime Coquelin <maxime.coquelin@redhat.com>, dev@dpdk.org,
 Thomas Monjalon <thomas@monjalon.net>
To: Olivier Matz <olivier.matz@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 5FAC016E
 for <dev@dpdk.org>; Wed,  2 May 2018 12:16:46 +0200 (CEST)
In-Reply-To: <20180502100837.zxy2k2x2p5pgczj2@neon>
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 5/2/2018 6:08 PM, Olivier Matz wrote:
> 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;

My bad, will fix it in a separate patch.

Thanks,
Jianfeng