Runtime: On porting .NET Core to FreeBSD

[mateusrodrigues]

Hello,

I'm working on a project with Google Summer of Code and FreeBSD to port the .NET Core runtime and SDK, as well as PowerShell, over to the FreeBSD platform. Right now, I'm gathering information on how to build and put together the tooling and runtime, since the components are pretty scattered around in different repositories.

I've started with CoreCLR and CoreFX to build a working runtime, which I'm basing on the 2.1.0 RC1 release -- commit hash a226c35 for CoreCLR and 8f968b9 for CoreFX. What I did was building them on Ubuntu Linux (which is an officially supported platform) to understand what the build results are and how to put them together, and then execute the same steps on FreeBSD to try to get the same result. During this process of building on Linux, I've come upon a couple questions which I'd like to discuss:

• I've built the CoreFX managed components on Windows (targeting Linux with build-managed.cmd -os=Linux -SkipTests), which resulted in a bunch of DLLs (exptected) and a couple Linux executables and .so files (not expected). These executables and .so files also appear when building CoreCLR native on Linux, which is expected. Why did they appear on the Windows build and which ones should I use, the ones that appear on the Windows CoreFX managed build or the ones that appear on the CoreCLR native build? They have the same filenames but different sizes -- the ones on the CoreCLR native build are about 10x larger.

• After getting the runtime working on Linux by creating the folder structure with the dotnet executable on top, the libhostfxr.so file inside the host/fxr/2.1.0-rc1 folder and the DLLs along with createdump and the native components of CoreFX inside the shared/Microsoft.NETCore.App/2.1.0-rc1 folder, I tried executing a little HelloWorld.dll program I created and built elsewhere on my own built-from-source runtime and it complained about a missing Microsoft.NETCore.App.deps.json file. In what step should it get built and how do I build it?

cc @Petermarcu @jkotas

I should mention this project is being mentored by @DragonSA (FreeBSD) and @davidchisnall (Microsoft Research and FreeBSD)

[stephentoub]

cc: @janvorli, @wfurt

Related:
https://github.com/dotnet/corefx/issues/1626
https://github.com/dotnet/corefx/issues/2046
https://github.com/dotnet/corefx/issues/24255
https://github.com/dotnet/corefx/issues/24259
https://github.com/dotnet/corefx/issues/24386
https://github.com/dotnet/corefx/issues/24538

[janvorli]

@mateusrodrigues that sounds like an exciting project! I'll be happy to support you in your effort. I've brought up support for Alpine Linux in all of our repos end to end and also fixed several build issues on the FreeBSD native side in the past.

@wfurt has recently done some work on fixing various managed components to work on FreeBSD properly.

I've built the CoreFX managed components on Windows (targeting Linux with build-managed.cmd -os=Linux -SkipTests), which resulted in a bunch of DLLs (exptected) and a couple Linux executables and .so files (not expected). These executables and .so files also appear when building CoreCLR native on Linux, which is expected. Why did they appear on the Windows build and which ones should I use, the ones that appear on the Windows CoreFX managed build or the ones that appear on the CoreCLR native build? They have the same filenames but different sizes -- the ones on the CoreCLR native build are about 10x larger.

The .so files you get on Windows are smaller because they are a release build stripped of all debugging symbols. They are not built on Windows, but rather extracted from NuGet packages. The .so files you build on Linux or FreeBSD are not stripped, which makes them about 10x larger, as you've mentioned.

After getting the runtime working on Linux by creating the folder structure with the dotnet executable on top, the libhostfxr.so file inside the host/fxr/2.1.0-rc1 folder and the DLLs along with createdump and the native components of CoreFX inside the shared/Microsoft.NETCore.App/2.1.0-rc1 folder, I tried executing a little HelloWorld.dll program I created and built elsewhere on my own built-from-source runtime and it complained about a missing Microsoft.NETCore.App.deps.json file. In what step should it get built and how do I build it?

Putting together a working runtime is more involved than what you did. The easiest way to start is to use the bootstrap CLI creation script that I have written some time ago. You can find it here: https://github.com/dotnet/source-build/blob/dev/release/2.1/scripts/bootstrap/buildbootstrapcli.sh
I've also put together a documentation on how to use it:
https://github.com/dotnet/source-build/blob/dev/release/2.1/Documentation/boostrap-new-os.md.

I've tried to use the script on FreeBSD in the past and it worked for the native components build (but I needed to do a couple of hacks in it to fix few things - @wfurt would know better since he's worked more with it on FreeBSD). As for managed components that you need to replace for FreeBSD too, you'll need to build them on Linux or Windows and then copy them over the same files in the CLI package. @wfurt should be able to tell you which ones you need.

Once you get the bootstrap CLI, you can use it for building managed components in coreclr, corefx and core-setup repos right on FreeBSD or just to build applications on FreeBSD.

Now it would be interesting to know what is the exact purpose of your project. If the goal is to integrate the end to end build into the FreeBSD so that FreeBSD native packages are produced, then it might be better to work in the https://github.com/dotnet/source-build repo. The goal of that project is to make the whole runtime buildable from scratch from sources of coreclr, corefx, core-setup and some other repos. However, it is still an effort in progress. @weshaggard should be able to tell you whether it is already in a state when you could base your work on that.

[mateusrodrigues]

@janvorli Awesome, thanks for your answer. As I'm working on a somewhat tight schedule, the main idea here is to have enough of the .NET Core SDK ported so that I can build PowerShell Core for FreeBSD. I'm still a little in the dark as to how much of the SDK should be ported, so I'm starting with the minimal: runtime first, then SDK tooling. But, after this project is completed, I do plan to work on porting the whole thing over so that FreeBSD becomes yet another option for us .NET developers to write .NET Core software.

I'll work on the information you provided and continue discussion on any further progress I achieve :smiley:

[janvorli]

@mateusrodrigues in that case, the bootstrap CLI creation as I've mentioned above should give you the fastest way to get PowerShell working.

[wfurt]

Did you look at the instructions here: https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD @mateusrodrigues ? CoreCLR and CoreFX no longer builds for me but that should be easy to fix. With that working we were able to pass most of the tests as well as run simple SDK functions.

As of 2.1 I was also able to run Linux SDK on FreeBSD 11 under Linux emulation.
I think that opens path for fixing source build as we can run Roslyn and compile managed code on FreeBSD. (right now with occasional crashes)

I'll look at my projects and I'll push out fixes I have so far to at least get to point we can build and instructions are valid.

[janvorli]

@mateusrodrigues, @eerhardt has discovered today few discrepancies in the doc and the script options. First, the script help describes an option -config, which doesn't exist anymore (the config is just passed in as -release or -debug or -checked now). Second, the doc has an example where the -rid option argument doesn't contain the architecture (x64), but it should have it. So for FreeBSD, the RID would be freebsd.11-x64

[ghost]

Also related https://github.com/dotnet/coreclr/issues/15674.

[mateusrodrigues]

@wfurt Yes, I followed those, although not on the current master branches, I used the 2.1.0 RC1 release. It doesn't build as well, still have to investigate further as to why. But I'll try again later with your PR dotnet/coreclr#18072.

@janvorli It took me a while but I was able to figure that one out 😄 I've been documenting the commands I'm running and, if it hasn't been done yet, I can submit some PRs correcting the existing docs.

[eerhardt]

@mateusrodrigues - I put up https://github.com/dotnet/source-build/pull/568 to fix the incorrect places I found in the bootstrap documentation. Please feel free to submit more as you find them :)

[wfurt]

CoreCLR should build again. CoreFX build issue is tracked by #29841.
I updated instructions with (experimental) notes, how to produce managed parts on FreeBSD.
That should open possibility for source-build.

BTW targeting Linux may give you 'hello world'. But you cannot get working product on FreeBSD.
I'd be happy to explain why, if it is not clear.

[mateusrodrigues]

@wfurt Yes! CoreCLR and CoreFX are now building on FreeBSD!
So, by 'targeting Linux' you mean building the stack over on Linux and using them on FreeBSD on top of the Linux compat layer?

[wfurt]

yes. using build constructs like "-os=Linux" or copying .dll assembly from Linux version.
It may work for many, but there are parts where source code is selected based on OS (OSGroup).
That impacts for example process management and networking - as BSD does not have same /proc as Linux and for many parts one needs to use sysctl() or other functions.

It also impacts test runs. Using -SkipTests is quick ay around it, but if we want to productize it, fixing tests and production code is great way to start.

It would be also nice to update documents as need - both dated CoreCLR FreeBSD doc as well as living WIKI document.

I don't know what is your exact plan @mateusrodrigues but I can give you ordered list of tasks I think needs to be done in order to productize this - or at least get it to point we can have daily CM runs.

[mateusrodrigues]

@wfurt The plan for this project is to port the .NET Core SDK over to FreeBSD so that I can build and utilize PowerShell Core on the platform. So yes, a production-ready product would be ideal and is my ultimate goal, specially since we're doing this in order to push the bits over to the ports tree and to the pkg infrastructure -- I should also say that, while I'm at it, having .NET Core available on FreeBSD for general development is also a secondary goal here.

But as I'm working on a tight schedule (GSoC will last up to early August), the way I'm going about this is to get to a point where I have PowerShell running (even if roughly) and then work my way back fixing things around, passing all the tests, and writing the ports. But right now, I'm just looking for a fast way to get there -- my objectives with this fast-lane-first approach is a better understanding of the whole build process and actually having a proof-of-concept working.

So, you can go ahead and send me the list, it certainly would be of great help once I get to the point of actually productizing this.

Also, even though I'm trying to go fast, I wasn't planning on actually using Linux versions of .NET, but trying to build a native FreeBSD-supported one. For this, I'm looking at the bootstrap CLI script in the source-build repository @janvorli mentioned.

I hope this helps understanding my plan better 😄 I hope it's a good one also!

[sec]

@wfurt @mateusrodrigues hey, if it's not a problem, could you also post this list somewhere online - I'm sure there are lots of BSD fans that can help if needed with some tasks, as we all would love to have fully working .net core on best OS :)

[ghost]

There used to be CI job for FreeBSD in CoreCLR, which was removed because things weren't moving forward.

[wfurt]

I sent @mateusrodrigues private email @sec and maybe he can track tasks on his project page.
There is list of known bugs and missing features. All should be labeled with os-freebsd.
If you (or anybody) pick one, please assign it to your self.
There is always work on documentation and testing.
source-build project moved on since last year and I think getting actual port working is nor more realistic.
We could also use freebsd-mono mailing list again if we want more coordination .
I'm always ready to point somebody at next roadblock :)
(and I may have some time to work on this again)

[SteveL-MSFT]

Awesome to see @mateusrodrigues working to get PowerShell Core working on FreeBSD! Once you get the coreclr/corefx components working, open an issue on PowerShell repo if you hit problems compiling the PowerShell Core code and I can help out.

[wfurt]

hello @mateusrodrigues , did you have chance to look at my email task list or suggestions from @sec

[mateusrodrigues]

Hello @wfurt @sec sorry for the delayed answer, I've been busy with school finals.

I just uploaded the priority list over at my gsoc18-progress repo, you can check it out here. I will work on item 1 today and report any blocking issues.

@SteveL-MSFT Will do! Thanks for reaching out!

[mateusrodrigues]

Hi, everyone! An update on the progress of the port:

I managed to bootstrap the .NET SDK for FreeBSD using @janvorli's script with all native components building and it's available here. Here are some observations about it:

• Running already compiled DLLs seems fine so far.
• dotnet restore works only by setting the variables SSL_CERT_FILE=/usr/local/share/certs/ca-root-nss.crt and DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0. @wfurt explained why. I believe I can work on a code fix for this one.
• dotnet build runs forever and never completes. This one I can't figure out why.

On this last issue, when I run dotnet build -v diag, it hangs on this line forever:

Using shared compilation with compiler from directory: /usr/home/mateus/git/source-build/scripts/bootstrap/freebsd.11-x64/dotnetcli/sdk/2.2.100-preview1-008958/Roslyn/bincore (TaskId:54)

And interrupting the execution spits out this perf summary, take a look at the last line there:

Task Performance Summary:
        6 ms  FindAppConfigFile                          1 calls
       10 ms  GetAssemblyVersion                         1 calls
       11 ms  ConvertToAbsolutePath                      2 calls
       12 ms  ShowPreviewMessage                         1 calls
       13 ms  GetRestoreProjectReferencesTask            1 calls
       15 ms  CheckForDuplicateItems                     3 calls
       15 ms  AssignCulture                              1 calls
       18 ms  Message                                    5 calls
       19 ms  AssignTargetPath                           4 calls
       21 ms  MakeDir                                    1 calls
       26 ms  Telemetry                                  1 calls
       30 ms  WriteLinesToFile                           2 calls
       33 ms  GetRestoreDotnetCliToolsTask               1 calls
       34 ms  CheckForImplicitPackageReferenceOverrides   2 calls
       50 ms  GetProjectTargetFrameworksTask             1 calls
       51 ms  WarnForInvalidProjectsTask                 1 calls
       52 ms  JoinItems                                  1 calls
       55 ms  Hash                                       2 calls
       60 ms  ProduceContentAssets                       1 calls
       69 ms  WriteCodeFragment                          1 calls
       71 ms  GetRestorePackageReferencesTask            1 calls
       71 ms  RemoveDuplicates                           5 calls
       82 ms  GetFrameworkPath                           1 calls
      106 ms  ResolvePackageFileConflicts                1 calls
      226 ms  GetRestoreSettingsTask                     1 calls
      367 ms  ResolvePackageAssets                       1 calls
      774 ms  ResolveAssemblyReference                   1 calls
     1213 ms  MsBuild                                    7 calls
     1607 ms  RestoreTask                                1 calls
    151066 ms  Csc                                        1 calls 

Can anyone shed a light on what might be happening here?

[eerhardt]

It appears the compiler (Csc or "Roslyn") is hanging during dotnet build. Can you try invoking it directly to see if it works in isolation?

/usr/home/mateus/git/source-build/scripts/bootstrap/freebsd.11-x64/dotnetcli/dotnet /usr/home/mateus/git/source-build/scripts/bootstrap/freebsd.11-x64/dotnetcli/sdk/2.2.100-preview1-008958/Roslyn/bincore/csc.dll

That should print a message asking for inputs.

Another thing to try is to turn off shared compilation, to see if that's the problem. You can do that by setting the env variable UseSharedCompilation=false (or you can set that in the .csproj file you are building:

<PropertyGroup>
  <UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>

[mateusrodrigues]

Looks like shared compilation is the problem. I altered the .csproj file to what you suggested and it worked. Running Csc in isolation also works, by the way. So, what's the concept behind shared compilation and why wouldn't it work?

[eerhardt]

So, what's the concept behind shared compilation and why wouldn't it work?

The shared compilation is a process that hangs around longer than just the current compilation request. It is an optimization feature of the compiler to reuse the same process for multiple compilation requests, that way the process already has all the assemblies loaded, and is "warmed up".

I assume something in the inter-process communication (sockets or pipes? - I'm not sure which is being used) isn't working, causing the compiler to hang.

@agocke and @jaredpar should be able to help give you some steps on how to debug the issue. Maybe using strace (or similar - not sure if that exists on FreeBSD) and see if you can see what is going wrong.

[agocke]

A debugger would be useful, but I presume that's not easily available on FreeBSD. We do have an environment variable, RoslynCommandLineLogFile which can be set to a path and then the client and server will write a log to that path. That's probably your second best option.

[wfurt]

sos plugin should work as well as 'truss' as equivalent of strace.

[wfurt]

BTW is there any OS specific code in Roslyn @agocke? I had to make some fixes in msbuild last year as it did not handle unknown (FreeeBSD) platform well.

[stephentoub]

I assume something in the inter-process communication (sockets or pipes? - I'm not sure which is being used) isn't working, causing the compiler to hang.

Either that (likely NamedPipeClient/ServerStream, which uses unix domain sockets), or some interaction with Process, which also has a lot of Linux-specific and macOS-specific code.

[wfurt]

I can try to run NamedPipe corefx tests. Process management is new for FreeBSD .. and there can be some bugs.

[agocke]

I think most of our Linux behavior checks should be POSIX compliant. I would expect the named pipe stuff to be far more fragile.

[agocke]

One thing that has caused hangs in the past is handles being inherited that are then waited on by one of the child processes. I believe the chain required three nested processes, where the innermost was waiting on the outermost, or something similar. On Windows we call CreateProcess with P/Invoke to prevent dangling handles. On Unix we can't P/Invoke, so we try to redirect I/O in every subprocess, hopefully preventing the child processes from catching the I/O from a parent process.

[janvorli]

One more thought - if Roslyn uses named mutexes for cross process synchronization, there can potentially be an issue in those. We use robust mutexes on platforms where they are available and file locks where they are not. I'm not sure what is the way we use on FreeBSD (the HAVE_FULLY_FEATURED_PTHREAD_MUTEXES symbol is defined during cmake config phase to indicate that).

[agocke]

We also use named mutexes, so that's another thing to check.

[wfurt]

Would that be covered by PAL coreclr tests @janvorli

[wfurt]

-- Performing Test HAVE_FULLY_FEATURED_PTHREAD_MUTEXES
-- Performing Test HAVE_FULLY_FEATURED_PTHREAD_MUTEXES - Success
-- Performing Test HAVE_FUNCTIONAL_PTHREAD_ROBUST_MUTEXES
-- Performing Test HAVE_FUNCTIONAL_PTHREAD_ROBUST_MUTEXES - Success

[janvorli]

Yes, there is a PAL test for that.

[mateusrodrigues]

Guys, check this one out: https://github.com/mateusrodrigues/gsoc18-progress/blob/master/dotnet/CoreCLR.md#pal-tests.

I ran the CoreCLR PAL tests and there's one that fails: threading/NamedMutex/test1/paltest_namedmutex_test1. Exit code: 1. I guess this is our guy?

[janvorli]

Yes, that's likely it then. This is the test for the mutexes I was talking about.

[mateusrodrigues]

A bit more information on my last comment. This is the error message I get for the threading/NamedMutex/test1/paltest_namedmutex_test1 test:

Child process: 'paltest_namedmutex_test1' failed at line 357. Expression: childRunningEvent.Release()

[wfurt]

I can pass the tests successfully if I force NAMED_MUTEX_USE_PTHREAD_MUTEX=0 in src/pal/src/include/pal/mutex.hpp @mateusrodrigues

as far as the notes from @agocke:
considering process like:

furt  7112   0.0  0.3  2659352 112992  1  IX+  14:19       0:12.49 dotnet exec /usr/home/furt/git/gsoc18-progress/blob/dotnetcli/sdk/2.2.100-preview1-008958/MSBuild.dll -maxcpucount -verbosity:m -restore /tmp/aa/aa.csproj -nologo -verbosity:quiet
furt  7115   0.0  0.2 21315892  65488  1  IX+  14:19       0:00.48 /usr/home/furt/git/gsoc18-progress/blob/dotnetcli/dotnet /usr/home/furt/git/gsoc18-progress/blob/dotnetcli/sdk/2.2.100-preview1-008958/Roslyn/bincore/VBCSCompiler.dll -pipename:furt.F.pdrYo55_DMW+svGqZPYAol5d3

I see trace like:

7112 100190: 12.465452918 socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 170 (0xaa)
 7112 100190: 12.465501094 connect(170,{ AF_UNIX "/tmp/CoreFxPipe_furt.F.pdrYo55_DMW+svGqZPYAol5d3" },51) ERR#2 'No such file or directory'
 7112 100190: 12.465913135 close(170)            = 0 (0x0)
 7112 100190: 12.467473115 socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 170 (0xaa)
 7112 100190: 12.467511277 connect(170,{ AF_UNIX "/tmp/CoreFxPipe_furt.F.pdrYo55_DMW+svGqZPYAol5d3" },51) ERR#2 'No such file or directory'
 7112 100190: 12.467921170 close(170)            = 0 (0x0)
  7115 100376: 12.469324517 bind(60,{ AF_UNIX "/tmp/CoreFxPipe_furt.F.pdrYo55_DMW+svGqZPYAol5d3" },51) = 0 (0x0)
 7112 100190: 12.469447120 socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 170 (0xaa)
 7112 100190: 12.469502792 connect(170,{ AF_UNIX "/tmp/CoreFxPipe_furt.F.pdrYo55_DMW+svGqZPYAol5d3" },51) ERR#61 'Connection refused'
 7112 100190: 12.469869049 close(170)            = 0 (0x0)
 7112 100190: 12.471453118 socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 170 (0xaa)
 7112 100190: 12.471510558 connect(170,{ AF_UNIX "/tmp/CoreFxPipe_furt.F.pdrYo55_DMW+svGqZPYAol5d3" },51) = 0 (0x0)
 7112 100190: 12.473413164 fcntl(170,F_SETFD,FD_CLOEXEC) = 0 (0x0)
 7115 100376: 12.484309508 fcntl(60,F_GETFL,)    = 2 (0x2)
 7115 100376: 12.484350820 fcntl(60,F_SETFL,O_NONBLOCK|0x2) = 0 (0x0)
 7112 100190: 12.521028991 fcntl(170,F_GETFL,)   = 2 (0x2)
 7112 100190: 12.521060396 fcntl(170,F_SETFL,O_NONBLOCK|0x2) = 0 (0x0)

The 7112 is trying to connect and it will eventually succeed. Both sides would make the socket non-blockinbg but there is no other activity after. no attempt to read or write. With SOCK_CLOEXEC set, there should be no inheritance problems (as well as I would see them my trace)

I looked at the Pipe code in corefx and all looks reasonable to me.

[wfurt]

I talk to @agocke today and I think I understand what the build expects and what is not working.
So far it looks like socket/pipe IO problem. I'm going to take a look.

[wfurt]

It seems like the problem was in processing kqueue events on FreeBSD. I made some changes to networking_pal in corefx and I was able to build completely coreclr and few other repos from source-build using bootstrap cli. msbuild and Roslyn seems to function without any observed problems. Named pipes tests from corefx now all pass. all pal tests form coreclr pass. sos plugin works and can be used to debug managed code.

corefx still fails to build because of some package/parameter mismatch. I'll dig into this next.

[mateusrodrigues]

Currently failing CoreFX tests on FreeBSD

• System.Threading.Tests

  • System.Threading.Tests.EventWaitHandleTests.Ctor_InvalidMode

• System.Collections.Tests.dll

  • Generic.Dictionary.DictionaryConcurrentAccessDetectionTests.DictionaryConcurrentAccessDetection_ReferenceTypeKey(comparerType: null)
  • Generic.Dictionary.DictionaryConcurrentAccessDetectionTests.DictionaryConcurrentAccessDetection_ReferenceTypeKey(comparerType: typeof(Generic.Dictionary.CustomEqualityComparerDummyRefType))
  • Generic.Dictionary.DictionaryConcurrentAccessDetectionTests.DictionaryConcurrentAccessDetection_ValueTypeKey(comparerType: null)
  • Generic.Dictionary.DictionaryConcurrentAccessDetectionTests.DictionaryConcurrentAccessDetection_ValueTypeKey(comparerType: typeof(Generic.Dictionary.CustomEqualityComparerInt32ValueType))

• System.Console.Tests.dll

  • WindowAndCursorProps.NonRedirectedCursorVisible

• System.Diagnostics.Process.Tests.dll

  • System.Diagnostics.Tests.ProcessTests.MinWorkingSet_GetNotStarted_ThrowsInvalidOperationException
  • System.Diagnostics.Tests.ProcessTests.TestProcessStartTime
  • System.Diagnostics.Tests.ProcessTests.TestMaxWorkingSet
  • System.Diagnostics.Tests.ProcessTests.MaxWorkingSet_GetNotStarted_ThrowsInvalidOperationException
  • System.Diagnostics.Tests.ProcessTests.TestMinWorkingSet
  • System.Diagnostics.Tests.ProcessTests.TestProcessorAffinity

• System.Drawing.Common.Tests.dll

  • All 5 tests in System.Drawing.Printing.Tests.PrintDocumentTests
  • All non-skippted tests in System.Drawing.Printing.Tests.PrinterSettingsTests

• System.IO.FileSystem.Tests.dll

  • System.IO.Tests.FileInfo_Exists.LockedFileExists
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 0, firstLength: 10, secondPosition: 1, secondLength: 2)
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 5)
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 4)
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 5)
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 6)
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 4)
  • System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 6)

• System.IO.MemoryMappedFiles.Tests.dll

  • System.IO.MemoryMappedFiles.Tests.MemoryMappedFileTests_CreateNew.TooLargeCapacity_Unix

• System.Net.Http.Unit.Tests.dll

  • 17 tests failing in System.Net.Http.Tests.HttpSystemProxyTest

• System.Net.NameResolution.Functional.Tests.dll

  • System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok(hostName: \\\"\\\")
  • System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntryAsync_HostString_Ok(hostName: \\\"\\\")
  • System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteGetHostByName_EmptyString_ReturnsHostName
  • System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteBeginEndGetHostByName_EmptyString_ReturnsHostName

• System.Net.NameResolution.Pal.Tests.dll

  • System.Net.NameResolution.PalTests.NameResolutionPalTests.TryGetAddrInfo_HostName
  • System.Net.NameResolution.PalTests.NameResolutionPalTests.TryGetAddrInfo_HostName_TryGetNameInfo

• System.Net.NetworkInformation.Functional.Tests.dll

  • All 8 tests in System.Net.NetworkInformation.Tests.NetworkInterfaceBasicTest
  • 7 out of 9 in System.Net.NetworkInformation.Tests.NetworkChangedTests

With OuterLoop enabled

• System.Xml.Xsl.XslTransformApi.Tests.dll
  
  
  
  • 24 tests failed
  
  

[wfurt]

Thanks @mateusrodrigues for good summary.

Do you have IPv6 enabled? Without it many tests will fail. That is just implicit assumption.
For some (like NetworkInfo & Drawing), there are already opened tickets. The collection and threading failures are probably most scary followed by file locking. I'll try to look at NameResolution and I'll open issue to track it.

[stephentoub]

Currently failing CoreFX tests on FreeBSD

If you're not already, you probably also want to run tests with /p:OuterLoop=true, as there are many tests categorized as "outer loop" that don't run by default.

[mateusrodrigues]

@stephentoub If I ran it correctly - ./run-test.sh -- /p:OuterLoop=true - I updated the list to include outer loop tests.

[stephentoub]

Thanks

[wfurt]

Hi @mateusrodrigues. I was not abe to reproduce System.Net.NameResolution* failures.
Make sure you have IPv6 enabled.

System.Xml.Xsl.XslTransformApi.Tests.dll would fail for me only when platform is incorrectly set to Linux in RunTests.sh. Please make sure category is set to nonfreebsd.

System.IO.MemoryMappedFiles.Tests.dll failure may be test issue. It expects generic IO exception but it will get arguments exception about filename too long.

[furt@toweinfu-d11 ~/git/source-build3/src/corefx/src/System.Net.NameResolution/tests/FunctionalTests]$ ../../../../Tools/msbuild.sh /t:rebuildandtest /p:pouterloop=true
Microsoft (R) Build Engine version 15.8.78-preview+gab48e64d18 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  System.Net.NameResolution.Functional.Tests -> /usr/home/furt/git/source-build3/src/corefx/bin/Unix.AnyCPU.Debug/System.Net.NameResolution.Functional.Tests/netstandard/System.Net.NameResolution.Functional.Tests.dll
  ----- start 17:32:09 =============== To repro directly: =====================================================
  pushd /usr/home/furt/git/source-build3/src/corefx/bin/tests/System.Net.NameResolution.Functional.Tests/netcoreapp-FreeBSD-Debug-x64
  chmod +x /usr/home/furt/git/source-build3/src/corefx/bin/testhost/netcoreapp-FreeBSD-Debug-x64//dotnet
  /usr/home/furt/git/source-build3/src/corefx/bin/testhost/netcoreapp-FreeBSD-Debug-x64//dotnet xunit.console.netcore.exe System.Net.NameResolution.Functional.Tests.dll  -xml testResults.xml -notrait Benchmark=true -notrait category=nonnetcoreapptests -notrait category=nonfreebsdtests  -notrait category=failing
  popd
  ===========================================================================================================
  /usr/home/furt/git/source-build3/src/corefx/bin/tests/System.Net.NameResolution.Functional.Tests/netcoreapp-FreeBSD-Debug-x64 ~/git/source-build3/src/corefx/src/System.Net.NameResolution/tests/FunctionalTests
  xUnit.net console test runner (64-bit .NET Core)
  Copyright (C) 2014 Outercurve Foundation.

  Discovering: System.Net.NameResolution.Functional.Tests
  Discovered:  System.Net.NameResolution.Functional.Tests
  Starting:    System.Net.NameResolution.Functional.Tests
  Finished:    System.Net.NameResolution.Functional.Tests

  === TEST EXECUTION SUMMARY ===
     System.Net.NameResolution.Functional.Tests  Total: 57, Errors: 0, Failed: 0, Skipped: 0, Time: 4.469s
  ~/git/source-build3/src/corefx/src/System.Net.NameResolution/tests/FunctionalTests
  ----- end 17:32:22 ----- exit code 0 ----------------------------------------------------------
  exit code 0 means Exited Successfully

[furt@toweinfu-d11 ~/git/source-build3/src/corefx/src/System.Net.NameResolution/tests/PalTests]$ ../../../../Tools/msbuild.sh /t:rebuildandtest /p:pouterloop=true
Microsoft (R) Build Engine version 15.8.78-preview+gab48e64d18 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  System.Net.NameResolution.Pal.Tests -> /usr/home/furt/git/source-build3/src/corefx/bin/Unix.AnyCPU.Debug/System.Net.NameResolution.Pal.Tests/netcoreapp/System.Net.NameResolution.Pal.Tests.dll
  ----- start 17:32:59 =============== To repro directly: =====================================================
  pushd /usr/home/furt/git/source-build3/src/corefx/bin/tests/System.Net.NameResolution.Pal.Tests/netcoreapp-FreeBSD-Debug-x64
  chmod +x /usr/home/furt/git/source-build3/src/corefx/bin/testhost/netcoreapp-FreeBSD-Debug-x64//dotnet
  /usr/home/furt/git/source-build3/src/corefx/bin/testhost/netcoreapp-FreeBSD-Debug-x64//dotnet xunit.console.netcore.exe System.Net.NameResolution.Pal.Tests.dll  -xml testResults.xml -notrait Benchmark=true -notrait category=nonnetcoreapptests -notrait category=nonfreebsdtests  -notrait category=failing
  popd
  ===========================================================================================================
  /usr/home/furt/git/source-build3/src/corefx/bin/tests/System.Net.NameResolution.Pal.Tests/netcoreapp-FreeBSD-Debug-x64 ~/git/source-build3/src/corefx/src/System.Net.NameResolution/tests/PalTests
  xUnit.net console test runner (64-bit .NET Core)
  Copyright (C) 2014 Outercurve Foundation.

  Discovering: System.Net.NameResolution.Pal.Tests
  Discovered:  System.Net.NameResolution.Pal.Tests
  Starting:    System.Net.NameResolution.Pal.Tests
  Finished:    System.Net.NameResolution.Pal.Tests

  === TEST EXECUTION SUMMARY ===
     System.Net.NameResolution.Pal.Tests  Total: 10, Errors: 0, Failed: 0, Skipped: 0, Time: 3.430s
  ~/git/source-build3/src/corefx/src/System.Net.NameResolution/tests/PalTests
  ----- end 17:33:10 ----- exit code 0 ----------------------------------------------------------
  exit code 0 means Exited Successfully

[wfurt]

I opened https://github.com/dotnet/corefx/issues/30899 for System.IO.FileSystem.Tests failures.
All failing tests are marked as [PlatformSpecific(~TestPlatforms.OSX)] so this may be test bug or OS shortcoming.

[mateusrodrigues]

Hi @wfurt, so here's what I've got:

• IPv6 is enabled over here, yet tests for System.Net.NameResolution* keep failing. I'll keep checking to see if there's any other knob I didn't turn.
• My RunTests.sh for System.Xml.Xsl.XslTransformApi.Tests.dll does contain nonfreebsd.

[janvorli]

@szadegan, that means that the linker was killed, it is likely that it has happened due to an excessive memory consumption. How much physical memory / swap space does your machine have? And how much of free memory was available before the build?

[wfurt]

BTW I tried about two weeks ago and coreclr build was broken again. I did not have a time to look at it and fix it.

[Szadegan]

@janvorli The memory is 1GB which was written its enough. But that really might be the issue since its a small VM on Azure. Will try it again then on a better machine :) thanks

[sec]

is this done, as GSoC have ended?

[mateusrodrigues]

Here's an update for you guys: the ports for dotnet and powershell have been submitted and are currently under review. There are changes I still need to upload, I'm working on them to do that as soon as possible. Right now, dotnet is building native components on the machine, however the managed parts are being downloaded pre-built - for the time being. Powershell is being built entirely locally on the machine.

Next steps, for the most part, include porting source-build to make the build process easier, since the dotnet-sdk port builds coreclr/corefx native, but downloads all other SDK components pre-built from the internet. Conversation on the port is happening here.

cc @sec

[sec]

Good news :)

[XVilka]

The PR seems completely abandoned - no updates for months.

[jkotas]

The active FreeBSD-related conversations are happening elsewhere: https://github.com/dotnet/corefx/issues/1626 or https://github.com/dotnet/core-setup/issues/5083

[wfurt]

Maybe this one should be closed. One can alway do query with os-FreeBSD label for coreclr and corefx to get list of current issues. Progress is slow, mostly reactive to reported issues like dotnet/coreclr#22124.

[mateusrodrigues]

Closing this issue. Will keep an eye for os-FreeBSD labeled ones.