Open rakista112 opened 2 years ago
Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.
Author: | rakista112 |
---|---|
Assignees: | - |
Labels: | `area-Diagnostics-coreclr`, `untriaged` |
Milestone: | - |
When I run it with strace, I see these errors before it writes the cocreate instance error
open("/lib/libuuid.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/local/lib/libuuid.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/libuuid.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/messages.mo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/messages.mo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/messages.mo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.UTF-8/LC_MESSAGES/messages.mo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/messages.mo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/messages.mo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
I fixed the uuid ones by running apk add libuuid
but I don't know where to get the messages.mo
files
@davmason
Hi @rakista112,
I am not familiar with that particular messages.mo file. This type of error is usually caused by your profiler having a dependency at build time that is unsatisfied at run time. It may be worthwhile to check your profiler build system to see what libraries you are building against, and making sure that all of those are installed in the container.
From searching around, it might be gettext or msgfmt, but I can't find anything definitive.
@davmason I tried installing gettext and still got the same messages. here's the full strace logs of just running an application strace -o strace_logs.txt dotnet AspNetCoreWebApp.dll
, if it helps
strace_logs.txt
Hi again @rakista112,
I am not sure how to help effectively here. The messages.mo is not provided as part of the runtime, it is something that is linked during the build process for the profiler you are trying to load.
You either have to find the library that provides it and install it on the target system, or statically link dependencies for the profiler
Okay, thanks I'll check my libraries/dependecies. I have a dependency on Boost 1.76 and coreclr PAL.
Just curious, why does it say CoCreateInstance when there is no COM on this platform - should that message be changed?
The hresult 0x8007007e
is ERROR_MOD_NOT_FOUND
- The specified module could not be found
. And the error "Loading profiler failed during CoCreateInstance.." is IDS_E_PROF_CCI_FAILED
: https://github.com/dotnet/runtime/blob/135e566b1fd4712c57f62e89234fca6fb2e5d674/src/coreclr/dlls/mscorrc/mscorrc.rc#L732
There error seems to be reported here: https://github.com/dotnet/runtime/blob/abb7df59eb4f8c813c07ddd6f46f94e59604577d/src/coreclr/vm/eetoprofinterfaceimpl.cpp#L321
Hope this helps!
On non-Windows, we still use a CLSID to instantiate the profiler, but it's an opaque GUID, and we handle it all ourselves? If that's the case, should we call these something different than a CLSID?
Just curious, why does it say CoCreateInstance when there is no COM on this platform - should that message be changed? On non-Windows, we still use a CLSID to instantiate the profiler, but it's an opaque GUID, and we handle it all ourselves? If that's the case, should we call these something different than a CLSID?
I agree the message is confusing for x-plat scenarios. It probably should say "Loading profiler failed" and instead of providing a CLSID it should provide the path.
The runtime implements a function called "FakeCoCreateInstance" which provides a cross-plat friendly mechanism for the profiler: https://github.com/dotnet/runtime/blob/d94ca5706c95b950719155905ec9a2d889160cbc/src/coreclr/utilcode/util.cpp#L233-L273
On non-Windows, we still use a CLSID to instantiate the profiler, but it's an opaque GUID, and we handle it all ourselves?
I believe we still use the CLSID in profiler class factory's CreateInstance call-
Description
We're getting a CoCreateInstance error when trying to load the profiler in my NetCore 3.0 app.
Reproduction Steps
Build coreclr in docker with
FROM mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.15-20211214164127-f0ea7ba
as base imageuse the release from https://codeload.github.com/dotnet/coreclr/tar.gz/release/3.0
add these statements in the docker file
RUN cd /code/coreclr/src/pal/src/libunwind/src/mi/ && sed -i '28d' dyn-info-list.c
RUN cd /code/coreclr && ./build.sh x64 release configureonly skipgenerateversion nopgooptimize skiptests
RUN cd /code/coreclr/bin/obj/Linux.x64.Release/src/pal && make
Set CORECLR_ENABLE_PROFILING, CORECLR_PROFILER and CORECLR_PROFILER_PATH environment variables
build your profiler with that library.
Run the net core 3.0 application
Expected behavior
The profiler should attach and create logs
Actual behavior
This error is printed when the application runs.
Loading profiler failed during CoCreateInstance. Profiler CLSID: '{************}'. HRESULT: 0x8007007e. Process ID (decimal): 161. Message ID: [0x2504]..NET Core SDK (3.1.416)
Regression?
No response
Known Workarounds
No response
Configuration
.net version: 3.1.416 Alpine x86_64 I don't know
Other information
No response