[clr-ios] PAL CreateThread crashes when initialized with PAL_InitializeDLL

[kotlarmilos]

Description

Components that statically link libcoreclrpal.a and initialize with PAL_InitializeDLL() crash with abort() when calling the PAL CreateThread.

Impact

The remote debugger profiler needs to spawn a background thread for its gRPC server during ICorProfilerCallback::Initialize. The crash prevents the debugger from starting at all. No debug session is possible without working around this.

Root cause

PAL_InitializeDLL() initializes the PAL for the calling thread but does not set up the process-level thread management infrastructure.

Fix

Use pthread_create/pthread_detach directly instead of the PAL CreateThread on Unix platforms.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[jkotas]

PAL_InitializeDLL() initializes the PAL for the calling thread but does not set up the process-level thread management infrastructure

PAL_InitializeDLL calls PAL Initialize method that initializes the process-level thread management infrastructure. My guess is that the problem is caused by multiple copies of the PAL in the process and wrong copy being initialized.

Workaround: use pthread_create/pthread_detach

That sounds good in general. We want to get rid of the PAL dependencies whenever we can, and delete the PAL eventually.

[kotlarmilos]

The fix is applied in the diagnostics repo.