Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
To: dev@openoffice.apache.org
References: <56D50F6F.4000301@apache.org>
From: Patricia Shanahan <pats@acm.org>
Message-ID: <56D5168B.4060909@acm.org>
Date: Mon, 29 Feb 2016 20:11:55 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56D50F6F.4000301@apache.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 2/29/2016 7:41 PM, Pedro Giffuni wrote:
> Hello;
>
> FWIW, I have looked at i126669 and Coverity confirms there is a bug there.
>
> CID 440168 (#1 of 1): Dereference after null check (FORWARD_NULL)9.
> var_deref_model: Passing null pointer "&pProfile->m_AccessLock" to
> function "pthread_mutex_unlock(pthread_mutex_t *)", which dereferences it.
>
> I suggest taking pthread_mutex_unlock outside the "if".
>
> I am attaching a patch: CC'd to orcmid jic the list rejects it.
>
> Of course it needs testing and you have to check the windows code too.

The current code does not unlock m_AccessLock in the non-null case until 
line 366, after doing more work on the profile. I am reasonably sure we 
should leave that alone. The question is what, if anything, should be 
done about m_AccessLock in the pProfile null case.

Patricia

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org