I just tried this against 1.0.2 and got a backtrace:
#0 0x77847c37 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x7784b028 in __GI_abort () at abort.c:89
#2 0x00401cfe in my_alloc (n=176) at a.c:4
#3 0x0044e525 in default_malloc_ex
On 6/3/16, 13:23 , "openssl-dev on behalf of Dan Kegel via RT"
wrote:
>1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.)
I compiled your death program, and confirm that it does abort on 1.0.2h.
So presumably no fix is necessary there:
$clang -I/opt/local/include -o t t.c -
1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.)
On Fri, Jun 3, 2016 at 10:08 AM, Rich Salz via RT wrote:
> Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and 1.0.1 is
> only getting security fixes at this time.
>
> --
> Ticket here: http://rt.openssl.org
Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and 1.0.1 is
only getting security fixes at this time.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://m
The commit
From: "Dr. Stephen Henson"
Date: Fri, 1 Apr 2011 15:46:03 +
Subject: [PATCH] Add additional OPENSSL_init() handling add dummy call to
(hopefully) ensure OPENSSL_init() is always linked into an application.
https://github.com/openssl/openssl/commit/c4acfb1fd049f52fb074b103
