| Summary: | Running anything dotnet/CoreCLR based in a devshell doesn't work | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Pseudo | Reporter: | Kai Ruhnau <kai.ruhnau> |
| Component: | pseudo | Assignee: | Seebs <seebs> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | pauldotknopf, randy.macleod, yp.pseudo.watcher, yp.watcher |
| Version: | unspecified | ||
| Target Milestone: | 2.8 M1 | ||
| Hardware: | x86 | ||
| OS: | x86_64 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Kai Ruhnau
2018-07-17 15:48:03 UTC
Peter, Can you determine if the problem is with pseudo, dotnet or if it's a irresistible force, immovable object conflict? Kai, are you aware of any tricks that dotnet plays that would conflict with pseudo's design? Hmm. So, looking at the threads, it looks like we've got an fopen64() call in some initialization code, and a clone call somewhere, and for some reason we've got stuff in lttng calling fcntl. Hmm. Okay, hypothesis: Something's trying to do traces, which means that for it to allow some syscall to complete, it has to be able to run something else, and the something else also blocks. I suspect dotnet has tracing going on, maybe? Possibly it can be turned off somehow. On Linux, dotnet indeed uses lttng-ust for tracing and initializes it here very early: https://github.com/dotnet/coreclr/blob/be7b9df6252593c918aaf7efa7f57f266349d179/src/pal/src/misc/tracepointprovider.cpp The last line in the function suggests that making that dlopen fail has no ill effect and indeed creating an empty libcoreclrtraceptprovider.so still allows `dotnet --info` to run outside of pseudo. Just removing the file is detected at a later stage and renders the Shared Framework unusable, though. With an empty file, the lttng based stack traces are gone together with two threads. It's still dead-locking in the devshell. I've followed the instructions from https://github.com/dotnet/symstore/blob/master/src/dotnet-symbol/README.md to get my hands on the debug symbols for better stack traces. The four remaining threads are then blocked at: - https://github.com/dotnet/coreclr/blob/v2.1.1/src/pal/src/thread/threadsusp.cpp#L125 - https://github.com/dotnet/coreclr/blob/v2.1.1/src/debug/debug-pal/unix/twowaypipe.cpp#L90 - https://github.com/dotnet/coreclr/blob/v2.1.1/src/pal/src/synchmgr/synchmanager.cpp#L2209 (without pseudo in the stack trace) - https://github.com/dotnet/coreclr/blob/v2.1.1/src/pal/src/thread/process.cpp#L2040 Hey guys, I created another bug report that is similar to this issue, but I believe it has more relevant information. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12908 There is a unrelated bug in .NET Core that causes a hang when using lttng. I've removed it completely from my build and is reflected in the bug I reported. Maybe we can migrate the discussion to the new bug to get rid of any static noise about lttng? I also reported this issue with Microsoft. https://github.com/dotnet/coreclr/issues/19682 Again, this issue doesn't have anything to do with lttng. Seebs, do you agree that this is duplicate of 12908 ? I think that looks very likely to be the same issue. Pseudo had a baked-in assumption that syscalls returned. In the specific case of opening a named pipe only for read or only for write, though, the call can block until the other end happens. As it happens, .NET relies on this for a special debug socket which is opened in a thread that then just waits for anything to happen. So this looks like the same thing -- fcntl is blocking because we've got a thread inside openat.c, calling underlying openat for "/tmp/clr-debug-pipe-...". |