System.Net.Http.Functional.Tests crashing on Debian10

[ViktorHofer]

./RunTests.sh: line 162:    23 Segmentation fault      (core dumped) "$RUNTIME_PATH/dotnet" exec --runtimeconfig System.Net.Http.Functional.Tests.runtimeconfig.json --depsfile System.Net.Http.Functional.Tests.deps.json xunit.console.dll System.Net.Http.Functional.Tests.dll -xml testResults.xml -nologo -nocolor -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing $RSP_FILE
/root/helix/work/workitem
----- end Wed 10 Feb 2021 01:03:19 PM UTC ----- exit code 139 ----------------------------------------------------------
exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

core.1000.23:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-47044-merge-d5fd37f62af34d4c92/System.Net.Http.Functional.Tests/core.1000.23?sv=2019-07-07&se=2021-03-02T12%3A42%3A55Z&sr=c&sp=rl&sig=g8mkLm73Sb7sg6WG936ZHIG1VSwKJoSqbLUWCp%2FggUU%3D

how-to-debug-dump.md:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-47044-merge-d5fd37f62af34d4c92/System.Net.Http.Functional.Tests/how-to-debug-dump.md?sv=2019-07-07&se=2021-03-02T12%3A42%3A55Z&sr=c&sp=rl&sig=g8mkLm73Sb7sg6WG936ZHIG1VSwKJoSqbLUWCp%2FggUU%3D

console.7a68dd86.log:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-47044-merge-d5fd37f62af34d4c92/System.Net.Http.Functional.Tests/console.7a68dd86.log?sv=2019-07-07&se=2021-03-02T12%3A42%3A55Z&sr=c&sp=rl&sig=g8mkLm73Sb7sg6WG936ZHIG1VSwKJoSqbLUWCp%2FggUU%3D

cc @dotnet/ncl

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

./RunTests.sh: line 162:    23 Segmentation fault      (core dumped) "$RUNTIME_PATH/dotnet" exec --runtimeconfig System.Net.Http.Functional.Tests.runtimeconfig.json --depsfile System.Net.Http.Functional.Tests.deps.json xunit.console.dll System.Net.Http.Functional.Tests.dll -xml testResults.xml -nologo -nocolor -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing $RSP_FILE
/root/helix/work/workitem
----- end Wed 10 Feb 2021 01:03:19 PM UTC ----- exit code 139 ----------------------------------------------------------
exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

core.1000.23:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-47044-merge-d5fd37f62af34d4c92/System.Net.Http.Functional.Tests/core.1000.23?sv=2019-07-07&se=2021-03-02T12%3A42%3A55Z&sr=c&sp=rl&sig=g8mkLm73Sb7sg6WG936ZHIG1VSwKJoSqbLUWCp%2FggUU%3D

how-to-debug-dump.md:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-47044-merge-d5fd37f62af34d4c92/System.Net.Http.Functional.Tests/how-to-debug-dump.md?sv=2019-07-07&se=2021-03-02T12%3A42%3A55Z&sr=c&sp=rl&sig=g8mkLm73Sb7sg6WG936ZHIG1VSwKJoSqbLUWCp%2FggUU%3D

console.7a68dd86.log:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-47044-merge-d5fd37f62af34d4c92/System.Net.Http.Functional.Tests/console.7a68dd86.log?sv=2019-07-07&se=2021-03-02T12%3A42%3A55Z&sr=c&sp=rl&sig=g8mkLm73Sb7sg6WG936ZHIG1VSwKJoSqbLUWCp%2FggUU%3D

cc @dotnet/ncl

Author:	ViktorHofer
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	6.0.0

[ManickaP]

I'm looking.

[ManickaP]

Should be fixed with #48193

[stephentoub]

Should be fixed with #48193

But we're still going to follow-up to understand and fix why it impacted SslStream, right? It seems there's a deeper issue lurking and potentially triggering exceptions unexpectedly.

[ManickaP]

If I get it right, it impacted SslStream because it depends on SafeHandle guarding against passing nulls to P/Invokes. To fix it, we would need add our own checks before every P/Invoke.

If you're talking about SslStream being disposed from one thread while being written to from another, that's a thing we use a lot in HttpClient (disposing stream in case of cancellation/timeout etc.) and that would require non-trivial changes.

But I might be missing the point you're trying to push us to 😄 Maybe @wfurt is better to answer your questions 😄

[stephentoub]

To fix it, we would need add our own checks before every P/Invoke.

We would fix whatever race is leading to us trying to use a null SafeHandle.

If you're talking about SslStream being disposed from one thread while being written to from another, that's a thing we use a lot in HttpClient

Exactly, which means we're potentially triggering a bunch of exceptions that a) we didn't intend to and could lead to functional problems and b) could be adding non-trivial overheads.