openssl: `openssl version` command hangs with 1.1.0c and `no-dso` option

Starting 1.1.0c, routine Windows builds (mingw 6.2.0, 32-bit, shared) using the no-dso option consistently fail when trying to run the command openssl.exe version. The process apparently hangs.

When the exact same build process, using the same tools, same options, is repeated against version 1.1.0b, the same command works as expected.
Throughout the process of removing build options, it turned out that removing no-dso, does resolve the problem with 1.1.0c.

Failure with 1.1.0c + no-dso: https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.933

Successful run when stepping back to 1.1.0b: https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.923#L3243

Successful run with 1.1.0c but without no-dso option: https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.935#L3326

It’s possible I’m using the no-dso option wrong, but it didn’t cause such problem with previous versions, including 1.0.2*. I’d argue a more graceful failure would be better, even if it’s a configuration mistake.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 24 (22 by maintainers)

Commits related to this issue

Stop init loops Under certain circumstances, the libcrypto init code would loop, causing a deadlock. This would typically happen if something in ossl_init_base() caused an OpenSSL error, and the err... — committed to levitte/openssl by levitte 8 years ago
Stop init loops Under certain circumstances, the libcrypto init code would loop, causing a deadlock. This would typically happen if something in ossl_init_base() caused an OpenSSL error, and the err... — committed to openssl/openssl by levitte 8 years ago
Stop init loops Under certain circumstances, the libcrypto init code would loop, causing a deadlock. This would typically happen if something in ossl_init_base() caused an OpenSSL error, and the err... — committed to openssl/openssl by levitte 8 years ago

Most upvoted comments

I’m also seeing the hang with no-shared on FreeBSD, introduced by commit 4af9f7fe79ff82b90c16969b7e5871435056377b. Current master is affected (that is, the above pull request above doesn’t solve it).

mdounin on Nov 11, 2016

I can see why. When no-dso is configured, no DSO_{whatever} macro defined, so there’s the call to DSO_dsobyaddr(), calling DSO_pathbyaddr(), with the null method, meaning meth->pathbyaddr is NULL, and we get a call DSOerr(), which throws us into an init loop.

The solution is to check for OPENSSL_NO_DSO in crypto/init.c. I’ve a PR coming up.

levitte on Nov 11, 2016