On 09/05/17 18:12, Nick Reilly wrote:
>
>
> On 2017-05-09 10:08 AM, Matt Caswell wrote:
>>
>> I'm not sure why this makes a difference. The return value of dlclose()
>> tells you whether there has been an error or not. Not whether the
>> library has actually been removed from address space. Or
> Sense of OPENSSL_USE_NODELETE has been reversed i.e. you want #ifdef
> and not #ifndef
Argh, you're right.
> Also I think its still fair game to try a dlclose() just that the
> dlclose() may return an error if OPENSSL_USE_NODELETE is not defined.
I'll just leave it as-is. Thanks for looking
On 2017-05-09 10:03 AM, Salz, Rich via openssl-dev wrote:
doesn't test for whether this is set. I think the shlibloadtest should only test
the dlclose() return value on if OPENSSL_USE_NODELETE is set.
Please see https://github.com/openssl/openssl/pull/3399
Sense of OPENSSL_USE_NODELETE
On 2017-05-09 10:08 AM, Matt Caswell wrote:
I'm not sure why this makes a difference. The return value of dlclose()
tells you whether there has been an error or not. Not whether the
library has actually been removed from address space. Or am I missing
your point?
dlclose() is returning an
On 09/05/17 15:03, Salz, Rich via openssl-dev wrote:
>> doesn't test for whether this is set. I think the shlibloadtest should only
>> test
>> the dlclose() return value on if OPENSSL_USE_NODELETE is set.
>
> Please see https://github.com/openssl/openssl/pull/3399
>
>> 2) crypto/init.c at
> doesn't test for whether this is set. I think the shlibloadtest should only
> test
> the dlclose() return value on if OPENSSL_USE_NODELETE is set.
Please see https://github.com/openssl/openssl/pull/3399
> 2) crypto/init.c at line 77 does "atexit(OPENSSL_cleanup)". If I try defining
>
Hi,
I just ported OpenSSL 1.1.0e to QNX and ran in to an issue on
shlibloadtest and it trying to unload the shared libraries in
conjunction with the code in crypto/init.c
1) crypto/init.c at line 106 deliberately leaks a reference to prevent
the library from unloading unless
On 09/05/17 01:22, Zubin Mevawalla wrote:
> I was curious if these were real null pointer dereference issues?
>
> CodeAi, an automated repair tool being developed at Qbit logic,
> suggested a couple of if-guards as fixes.
>
> The first was in crypto/async/async_wait.c on line 157. `prev` is
>
