runtime: Android - coreclr_initialize failed - status: 0x80004005 because of mkfifo call

When cross-building CoreCLR for Android, running a simple Hello World application fails with the following output:

coreclr_initialize failed - status: 0x80004005

Setting COMPlus_BreakOnHR=80004005 and some stepping through the code with lldb reveals that the root cause for this failure is here:

* thread dotnet/coreclr#1, name = 'corerun', stop reason = breakpoint 10.1
    frame #0: libcoreclr.so`TwoWayPipe::CreateServer(this=0x000000555ee45938, id=13506) at twowaypipe.cpp:29
   26
   27       unlink(m_inPipeName);
   28
-> 29       if (mkfifo(m_inPipeName, S_IRWXU) == -1)
   30       {
   31           return false;
   32       }

with m_inPipeName set to /data/local/tmp/clr-debug-pipe-13506-424747-in.

This is the same issue as seen previously seen by @cydhaselton and @janvorli in https://github.com/dotnet/coreclr/issues/917#issuecomment-262652992.

Long story short (see e.g. this discussion on the android-ndk mailing list), there is no reliable way to create a named pipe on Android that can be shared accross processes/applications. (@cydhaselton was able to do it in Termux because Termux is deployed as an Android application).

Looking at the code, it appears these named pipes are used to enable a remote debugger to connect. I’m not sure that scenario makes a lot of sense on Android, and it appears this code is guarded with an FEATURE_DBGIPC_TRANSPORT_DI feature flag.

Net, I’d like to understand if it would be safe to disable this feature alltogether on Android? Is there a specific location in the CMake files where we could control this flag?

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 21 (21 by maintainers)

Most upvoted comments

@cydhaselton I have seen it, but then couldn’t find it again. There is no reason for the casing. On Windows, the filesystem is not case sensitive and so it doesn’t matter if the case in the #include doesn’t match the actual case of the file. In the early days of porting coreclr to Unix, we have changed all files that were included / compiled on Linux to lowercase to fix the problem. But some files that were windows specific remained.

janvorli on Feb 28, 2017