> From: openssl-users [mailto:[hidden email]] On Behalf Of Brian.Chou
> Sent: Tuesday, June 12, 2018 23:40
> Can you help to explain what changes are made between “1.0.2h” and “1.0.2i” that may cause this issue?
The OpenSSL changelog describes the high-level differences between each pair of consecutive versions.
For details, you'll need to look at the git history, or extract the sources and diff them. In this case, you're probably only interested in the differences in libcrypto, so diffing the crypto source trees is probably sufficient. (It might be elsewhere, but that's the place to start.)
It'd be faster, though, to debug the openssl s_client run and see where the exception is being thrown. It's a c0000005 - an addressing violation - so there's a decent chance that it's raised in or near (in terms of stack frames) where the actual cause exists in the code. (Addressing violations are synchronous exceptions caused by invoking undefined behavior, so they *can* have remote causes, such as earlier heap corruption, but there's a decent probability of hitting the exception soon after generating the invalid address.) You'll need symbol (PDB) files to get much useful information, but if you're building OpenSSL you can easily arrange for those.
Of course there are other possibilities, such as changes to the build flags between the two versions. And I haven't looked to see whether the OpenSSL sources for 1.0.2h or 1.0.2i include Atom assembly modules; that would be something else to check.
Distinguished Engineer, Micro Focus
> On Jun 13, 2018, at 12:31 PM, Michael Wojcik <[hidden email]> wrote:
> It's a c0000005 - an addressing violation - so there's a decent chance that it's raised in or near (in terms of stack frames) where the actual cause exists in the code.
Perhaps a memory alignment issue, that is somewhat peculiar
to the SOC in question. I'd try a non ASM build, and if that
passes, look for changes in the ASM code, or changes in the