-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.Security.Cryptography.Xml.Tests fail on mono linux ARM64 #50300
Comments
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks Issue DetailsTests are crashing with segfault while initializing OpenSSL. Interesting snippets from log.
Observation from @bartonjs is that threads 10 and 13 should not be inside libcrypto before thread 11 completes initialization.
|
It's also weird that the already-running OpenSSL is libcrypto.so.1.0.0... I'd expect Ubuntu 18.04 to have libcrypto.so.1.1 (with maybe also having 1.0.0 as a fallback). I don't see any obvious linking of the mono CLR to OpenSSL, so I don't know how it would have gotten into the process already to be running things. The failing thread is in CryptoNative_EnsureOpenSslInitialized, called by the CryptoInitializer cctor, so that should be gating down to single threaded access (though I suppose it could end up being called concurrently from up to 4 different libraries' version of the cctor. (S.S.C.Algorithms, S.S.C.OpenSsl, S.S.C.X509Certificates, System.Net.Security all end up having one, IIRC) -- not sure what about that would cause dlopen to segfault, though. |
Happened again here: |
I got this issue again on my PR, but note that it is mono x64 leg, and not ARM64. |
Looks like the same issue I just hit in another PR:
|
@stephentoub Your callstack looks a bit different. We hit the abort() call in InitializeOpenSSLShim, meaning we couldn't find an appropriate libssl. The previous ones were SIGSEGV via a dlopen call. |
I believe ("hope"?) that the DlOpen-related errors should stop happening as of #55370. We only ever go through library loading and initialization once each now. If I'm wrong, then at the very least, we'll stop getting red herring callstacks, and maybe we can make more sense of them. |
Tests are crashing with segfault while initializing OpenSSL.
https://dev.azure.com/dnceng/public/_build/results?buildId=1058396&view=ms.vss-test-web.build-test-results-tab&runId=32633134&resultId=180106&paneView=attachments
core.1001.99:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-50288-merge-db294f34f17e4673ad/System.Security.Cryptography.Xml.Tests/core.1001.99?sv=2019-07-07&se=2021-04-15T18%3A31%3A06Z&sr=c&sp=rl&sig=y51iybChEIg%2B9i1C8IWdd8szXZPbfdQZ9pqMpk3XUz8%3D
console.3a06eda1.log:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-50288-merge-db294f34f17e4673ad/System.Security.Cryptography.Xml.Tests/console.3a06eda1.log?sv=2019-07-07&se=2021-04-15T18%3A31%3A06Z&sr=c&sp=rl&sig=y51iybChEIg%2B9i1C8IWdd8szXZPbfdQZ9pqMpk3XUz8%3D
Interesting snippets from log.
Observation from @bartonjs is that threads 10 and 13 should not be inside libcrypto before thread 11 completes initialization.
The text was updated successfully, but these errors were encountered: