Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building the CLI gives a out of memory exception #4693

Closed
davidfowl opened this issue Dec 26, 2015 · 22 comments
Closed

Building the CLI gives a out of memory exception #4693

davidfowl opened this issue Dec 26, 2015 · 22 comments
Assignees
Labels
Milestone

Comments

@davidfowl
Copy link
Member

On OSX El Capitan.

~/dev/cli
*** Testing stage2... ***
Publishing E2E for DNXCore,Version=v5.0/osx.10.10-x64
Compiling Microsoft.Extensions.DependencyModel for DNXCore,Version=v5.0

Unhandled Exception: OutOfMemoryException.
Copy From: /Users/dfowler/dev/cli/artifacts/tests/Microsoft.Extensions.DependencyModel.dll
       To: /Users/dfowler/dev/cli/artifacts/osx.10.10-x64/stage2/bin/
Copy From: /Users/dfowler/dev/cli/artifacts/tests/Microsoft.Extensions.DependencyModel.pdb
       To: /Users/dfowler/dev/cli/artifacts/osx.10.10-x64/stage2/bin/

Compilation failed.
    0 Warning(s)
    0 Error(s)

Time elapsed 00:00:01.3028968

Published 0/1 projects successfully
@davidfowl davidfowl changed the title Building the CLI give a out of memory exception Building the CLI gives a out of memory exception Dec 26, 2015
@TheRealPiotrP
Copy link
Contributor

I'm seeing the same. This only started yesterday and only repros on el cap. Exception is getting swallowed so no idea where this is coming from...

@davidfowl
Copy link
Member Author

So 2 things:

  • why is the ci passing?
  • can we revert the change that is causing it?

@TheRealPiotrP
Copy link
Contributor

CI is not on El Cap yet. Have you identified the offending PR?

@davidfowl
Copy link
Member Author

F# support PR is what makes it fail

/cc @KevinRansom @enricosada

@enricosada
Copy link
Contributor

I have not added an E2E test for fsharp.

I cannot repro. No El cap locally in OS X

@brthor
Copy link
Contributor

brthor commented Dec 29, 2015

We are seeing this our VSO builds for OS X.

Relevant Error:

2015-12-23T09:18:53.228Z: Publishing �[33mE2E�[39m for �[33mDNXCore,Version=v5.0�[39m/�[33mosx.10.10-x64�[39m
2015-12-23T09:18:54.069Z: Compiling �[33mMicrosoft.Extensions.DependencyModel�[39m for �[33mDNXCore,Version=v5.0�[39m
2015-12-23T09:18:54.692Z: 
2015-12-23T09:18:54.692Z: Unhandled Exception: OutOfMemoryException.

This seems to have appeared with the Server GC change to CoreHost.
PR dotnet/cli#638

@schellap

@schellap
Copy link

Taking a look

@schellap
Copy link

The PR dotnet/cli#658 undoes SERVER_GC change for CLI which causes this problem.

We need to resolve #4567 to enable SERVER_GC by default [OR] at least we should have a temporary solution of disabling SERVER_GC using an environment flag, so VSO can set this variable to switch off. Otherwise it is enabled. How does that sound?

https://github.com/dotnet/cli/pull/658/files

@schellap
Copy link

@gkhanna79
Copy link
Member

@janvorli Can you please take a look to understand why enabling Server GC would trigger OOM on OSX Elcapitan?

@kouvel kouvel self-assigned this Jan 14, 2016
@kouvel
Copy link
Member

kouvel commented Jan 14, 2016

I'll take a look at this

@schellap schellap reopened this Feb 12, 2016
@schellap
Copy link

Reopening... @piotrpMSFT @sergiy-k

@davidfowl
Copy link
Member Author

Finally!

@andyleejordan
Copy link
Member

Noticed there is no milestone... Also just hit this, would love to compile a project on El Capitan ⛵

@gkhanna79
Copy link
Member

This is affecting vso osxbuild

@gkhanna79 gkhanna79 reopened this Feb 12, 2016
@leecow leecow closed this as completed Feb 12, 2016
@gkhanna79
Copy link
Member

Clicked the wrong button on phone :(

@gkhanna79 gkhanna79 reopened this Feb 12, 2016
@andyleejordan
Copy link
Member

Just to make it obvious (since I pieced it together from a couple linked threads):

export COREHOST_SERVER_GC=0

And then build happily :)

(With ulimit -S -n 4096 being the work-around to restore without crashing; unrelated but also needed on OS X.)

@gkhanna79
Copy link
Member

@janvorli ptal

@davidfowl
Copy link
Member Author

FYI I turned it off by default for now

@gkhanna79
Copy link
Member

@davidfowl Which PR?

@schellap
Copy link

@davidfowl please @ mention on the PR or commit message for the host, #WorldMovedUnderFeet

sergiy-k referenced this issue in sergiy-k/coreclr Feb 18, 2016
…rve VA

This change modifies the MAPMapPEFile in PAL to use ExecutableAllcator
instead of mmap in order to reserve VA for managed executable images. This
allows all NI images to be located near each other and close to the
coreclr library, which also allows the runtime to generate code that is
more efficient (by avoiding usage of jump stubs).

It also fixes an issue (https://github.com/dotnet/cli/issues/652) where
CLI fails with OutOfMemoryException which turned out to be related to
loading NI files. Due to a certain allocation pattern, mmap can place an
NI file at a region of virtual address space that does not have any free
memory around the NI images. As a result, when the runtime needs to
allocate memory for jump stubs for the image it cannot find any available
memory near the image and fails with OutOfMemoryException.
ellismg referenced this issue in dotnet/coreclr Feb 19, 2016
…rve VA

This change modifies the MAPMapPEFile in PAL to use ExecutableAllcator
instead of mmap in order to reserve VA for managed executable images. This
allows all NI images to be located near each other and close to the
coreclr library, which also allows the runtime to generate code that is
more efficient (by avoiding usage of jump stubs).

It also fixes an issue (https://github.com/dotnet/cli/issues/652) where
CLI fails with OutOfMemoryException which turned out to be related to
loading NI files. Due to a certain allocation pattern, mmap can place an
NI file at a region of virtual address space that does not have any free
memory around the NI images. As a result, when the runtime needs to
allocate memory for jump stubs for the image it cannot find any available
memory near the image and fails with OutOfMemoryException.
@kouvel kouvel assigned sergiy-k and unassigned kouvel Feb 23, 2016
@TheRealPiotrP
Copy link
Contributor

This is fixed.

wli3 referenced this issue in wli3/cli Jul 14, 2017
Pass the correct delimiter for DefineConstants for C# and VB
@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the 1.0.0-rtm milestone Jan 31, 2020
rainersigwald pushed a commit to rainersigwald/sdk that referenced this issue Jul 20, 2020
* Update dependencies from https://github.com/dotnet/cli build 20200717.1

Microsoft.DotNet.Cli.Runtime
 From Version 3.1.400-preview.20365.4 -> To Version 3.1.400-preview.20367.1

* Update dependencies from https://github.com/dotnet/cli build 20200717.2

Microsoft.DotNet.Cli.Runtime
 From Version 3.1.400-preview.20365.4 -> To Version 3.1.400-preview.20367.2

* Remove darc int feeds

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Jason Zhai <AzureTest@vwuzhai002.redmond.corp.microsoft.com>
GangWang01 pushed a commit to GangWang01/sdk that referenced this issue Jun 7, 2022
[main] Update dependencies from dotnet/command-line-api


 - fix build after contract change
GangWang01 pushed a commit to GangWang01/sdk that referenced this issue Jun 21, 2022
[main] Update dependencies from dotnet/command-line-api


 - fix build after contract change
GangWang01 pushed a commit to GangWang01/sdk that referenced this issue Jul 11, 2022
[main] Update dependencies from dotnet/command-line-api


 - fix build after contract change
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests