CoreCLR fails to load if lttng fails

[ericeil]

If running in an environment where lttng does not work, CoreCLR fails to load, with an error message like this:

libust[14067/14068]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttng-ust-comm.c:886)
libust[14067/14068]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttng-ust-comm.c:886)
libust[14067/14069]: Error: Error opening shm /lttng-ust-wait-5-0 (in get_wait_shm() at lttng-ust-comm.c:886)
libust[14067/14069]: Error: Error opening shm /lttng-ust-wait-5-0 (in get_wait_shm() at lttng-ust-comm.c:886)
coreclr_initialize failed - status: 0x80004005

This currently happens in the "Ubuntu on Windows" environment in the latest Windows 10 preview, for example. This issue and #5478 appear to be the only blockers to basic managed code execution in that environment.

As a workaround, it seems to work if I delete libcoreclrtraceptprovider.so.

Since LTTng is not critical functionality for CoreCLR (application code will work just fine without it), it would be nice if we could detect this failure and handle it more gracefully, perhaps by simply disabling LTTng usage for the process.

@brianrob @ramarag

[brianrob]

LTTng is already a soft-dependency. If it's not installed you should get no output. This is likely specific to Ubuntu for Windows.

[brianrob]

To clarify my earlier comment, you should get no output on LTTng and the app should run as expected.

[ramarag]

ensure that at line : https://github.com/dotnet/coreclr/blob/master/src/pal/src/misc/tracepointprovider.cpp#L106, the load fails for your case. it should not be loading libcoreclrtraceptprovider.so for WSL, probably the load emulation is not as strict on linux

[ericeil]

Ah, yes, this is happening because I followed the instructions to build CoreCLR, and thus installed the liblttng-ust-dev package. If I remove that package then CoreCLR loads.

It would be nice to be able to build and run CoreCLR, though. :)

[joshfree]

@ramarag @brianrob can we harden coreclr for this scenario as @ericeil suggests; that way .net core can run on bash on windows without requiring changes from the windows guys?

[brianrob]

@joshfree, we've actually already hardened this scenario a bunch to ensure that if LTTng isn't present, that everything goes well. Per @ericeil's comment above, LTTng was on the machine as it is a build-time dependency, but something failed at runtime. Removing LTTng from the machine made this error go away.

We can debug this and try to figure out if there is a nice way to work around it, but I'm not sure that there will be as the errors are already in LTTng code, not CoreCLR code.

[ramarag]

@joshfree to make it work out of the box, possibly we could do one of 3 things:

1. Add the complete lttng tooling as the pre req to build on Ubuntu. [ need to verify if lltng actually works in WSL]
2. Figure out if the load modes difference between Ubuntu and WSL and fail the load for WSL
3. Stop bin placing libcoreclrtraceptprovider.so with libcoreclr.so. As tracing needs to be enabled explicitly using external tooling, we could place it at the time of enabling [ probably we should not be doing it]

[joshfree]

@dethoma would it be possible to help @ramarag on option 2?

[ramarag]

cc @gkhanna79

[mikeschuld]

@ericeil Even with liblttng-ust-dev removed, I am still getting the same lttng errors when trying to call dotnet run on the standard dotnet new content. dpkg is telling me that liblttng-ust-ct12 and liblttng-ust0 are still installed and cannot be removed without also removing dotnet (I installed from the package, not by building)

It sounds like on your end you have things running now, so was there some other step that I missed? I have also already run execstack -c /usr/share/dotnet/bin/libcoreclr.so to get this far. Do I just need to build it myself? It seems like for this to really work "out of the box" that the package version should not have these issues either.

[mjsabby]

@ramarag Something like Option 3 but instead we do could a check to see if lttng is enabled? There are multiple reasons why depending on lttng during the early boot process isn't necessarily desirable. I think the fact that file exists is not enough and we need another indicator that we should even search for the libcoreclrtraceptprovider.so

@mikeschuld For the time being, just delete the libcoreclrtraceptprovider.so from your directory and things will work.

[brianrob]

Today, LTTng has a requirement that we load at start-up. If we don’t do this (e.g. delete the tracepoint provider lib), then all tracepoints become no-ops for the life of the process. So, we load at start-up so that we have the ability to profile later if we need to.

From: Mukul Sabharwal [mailto:notifications@github.com]
Sent: Wednesday, April 13, 2016 3:08 AM
To: dotnet/coreclr coreclr@noreply.github.com
Cc: Brian Robbins brianrob@microsoft.com
Subject: Re: [dotnet/coreclr] CoreCLR fails to load if lttng fails (#4132)

@ramaraghttps://github.com/ramarag Something like Option 3 but instead we do could a check to see if lttng is enabled? There are multiple reasons why depending on lttng during the early boot process isn't necessarily desirable. I think the fact that file exists is not enough and we need another indicator that we should even search for the libcoreclrtraceptprovider.so

@mikeschuldhttps://github.com/mikeschuld For the time being, just delete the libcoreclrtraceptprovider.so from your directory and things will work.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/coreclr/issues/4132#issuecomment-209351357

[gkhanna79]

Based upon this discussion, it appears that we should understand why loading libcoreclrtraceptprovider.so is different from between WSL and Ubuntu and drive the discussion from there.

Unless we want to treat WSL as a different platform target (e.g. known as RID - runtime identifier - in nuget parlance) from Ubuntu, we should continue to binplace libcoreclrtraceptprovider.so as the file, in addition to getting binplaced, is packaged in the Ubuntu nuget package for CoreCLR as well.

If WSL can fail the load, then libcoreclr execution should be able to continue normally.

@dethoma Are you the right person to look into the load issue?

[gkhanna79]

CC @janvorli

[joshfree]

We don't want to treat WSL as a different platform target (with a separate RID) from Ubuntu. I believe given the investigation that this bug should be moved to https://github.com/Microsoft/BashOnWindows/issues for the BashOnWindows team to resolve.

[gkhanna79]

@ramarag Can you please move the issue to the other repo?

[ramarag]

closing this ans opening in WSL team's issues [https://github.com/microsoft/WSL/issues/302]