Bug 18327 - java.lang.OutOfMemoryError: Java heap space
Summary: java.lang.OutOfMemoryError: Java heap space
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 4.13.x
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Radek Doulik
URL:
Depends on:
Blocks:
 
Reported: 2014-03-12 15:40 UTC by James Clancey
Modified: 2015-10-31 11:29 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test Project packages bin obj scrubbed out (191.03 KB, application/x-bzip2)
2015-10-31 11:29 UTC, Andrew Page
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 18327 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description James Clancey 2014-03-12 15:40:46 UTC
I just received an awesome build error that let me confused and makes it look like our products are broken. Yes we  know its an issue with the Java heap size, but as an end user I it looks broken to me.  We obviously know its an issue because we added a nice little UI to increase the heap size.

When a user gets this error, we should give them something meaningful and tell them to go increase the heap size. Or better yet, offer to do it for them. 

Something else we should do, is since we know using Google Maps will almost always trigger this, we can tell them when they reference that lib that they should increase the heap size. 


Also are there any negative side effects to increasing it by default?

Target _CompileDex:
		  JavaSourceFiles:
		  JavaLibraries:
		  ExternalJavaLibraries:
		  AdditionalJavaLibraryReferences:
		    /Users/Clancey/Downloads/ProbationMobilityApp/Components/googleplayservicesjellybean-15.0/lib/android/15/content/google-play-services/libproject/google-play-services_lib/libs/google-play-services.jar
		  DoNotPackageJavaLibraries:
		Tool /usr//bin/java execution started with arguments: -jar /Users/Clancey/Library/Developer/Xamarin/android-sdk-mac_x86/build-tools/17.0.0//lib/dx.jar --no-strict --dex --output=obj/Debug/android/bin/classes.dex obj/Debug/android/bin/classes /Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v4.4/mono.android.jar /Users/Clancey/Downloads/ProbationMobilityApp/Components/googleplayservicesjellybean-15.0/lib/android/15/content/google-play-services/libproject/google-play-services_lib/libs/google-play-services.jar 
		
		UNEXPECTED TOP-LEVEL ERROR:
		java.lang.OutOfMemoryError: Java heap space
			at com.android.dx.util.FixedSizeList.<init>(FixedSizeList.java:38)
			at com.android.dx.rop.code.InsnList.<init>(InsnList.java:32)
			at com.android.dx.cf.code.Ropper.processBlock(Ropper.java:889)
			at com.android.dx.cf.code.Ropper.doit(Ropper.java:639)
			at com.android.dx.cf.code.Ropper.convert(Ropper.java:252)
			at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:256)
			at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:134)
			at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:87)
			at com.android.dx.command.dexer.Main.processClass(Main.java:487)
			at com.android.dx.command.dexer.Main.processFileBytes(Main.java:459)
			at com.android.dx.command.dexer.Main.access$400(Main.java:67)
			at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:398)
			at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)
			at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
			at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
			at com.android.dx.command.dexer.Main.processOne(Main.java:422)
			at com.android.dx.command.dexer.Main.processAllFiles(Main.java:333)
			at com.android.dx.command.dexer.Main.run(Main.java:209)
			at com.android.dx.command.dexer.Main.main(Main.java:174)
			at com.android.dx.command.Main.main(Main.java:91)
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: error : Tool exited with code: 3. Output: 
UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: Java heap space
	at com.android.dx.util.FixedSizeList.<init>(FixedSizeList.java:38)
	at com.android.dx.rop.code.InsnList.<init>(InsnList.java:32)
	at com.android.dx.cf.code.Ropper.processBlock(Ropper.java:889)
	at com.android.dx.cf.code.Ropper.doit(Ropper.java:639)
	at com.android.dx.cf.code.Ropper.convert(Ropper.java:252)
	at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:256)
	at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:134)
	at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:87)
	at com.android.dx.command.dexer.Main.processClass(Main.java:487)
	at com.android.dx.command.dexer.Main.processFileBytes(Main.java:459)
	at com.android.dx.command.dexer.Main.access$400(Main.java:67)
	at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:398)
	at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)
	at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
	at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
	at com.android.dx.command.dexer.Main.processOne(Main.java:422)
	at com.android.dx.command.dexer.Main.processAllFiles(Main.java:333)
	at com.android.dx.command.dexer.Main.run(Main.java:209)
	at com.android.dx.command.dexer.Main.main(Main.java:174)
	at com.android.dx.command.Main.main(Main.java:91)
 
	Task "CompileToDalvik" execution -- FAILED
Comment 1 Ram Chandra 2014-03-13 07:07:31 UTC
I tried to reproduce this issue and i am able to reproduce this issue.

Steps to reproduce:

1. Open "MapAndLocationSample" on Android
2. Open ".csproj" in text editor 
3. Change the JavaMaximumHeapSize "1G" to "64M"
3. Save the ".csproj" file.
3. Build the application

I observer that if I increase the JavaMaximumHeapSize (1G) in ".csproj"  I am not getting any build error. but f I remove this element I am facing this error and when  If I add the following line in ". csproj" , it removes the error:

<PropertyGroup>
    <JavaMaximumHeapSize>1G</JavaMaximumHeapSize>
</PropertyGroup>

screencast:http://www.screencast.com/t/Q78yV1Y5l1

Environment:
Mac 10.7.5
Xamarin Studio: 4.2.3 (build 60)
Xamarin.Android : 4.12.1
Comment 2 Jonathan Pryor 2014-03-13 10:48:49 UTC
I can think of two ways to address this:

1. <CompileToDalvik/> could interpret the error messages, and if java.lang.OutOfMemoryError is observed then it could report an XA.... error stating that the $(JavaMaximumHeapSize) property should be updated.

For sanity, this is the least we should do.

2. Add an assembly-level custom attribute that could be used to hint at the $(JavaMaximumHeapSize) value that should be used. The build process could extract all such values from all referenced assemblies and use the max value found.

I'm not sure how sane (2) is, as (offhand) I don't know if the assemblies have all been resolved by the time <CompileToDalvik/> is executed.
Comment 4 Andrew Page 2015-10-31 11:29:53 UTC
Created attachment 13598 [details]
Test Project   packages bin obj scrubbed out

Whilst trying to develop a test case for another bug I ran into this issue.   This was a 'fresh' project with an updated Xam studio, couple source files added 1 5k(barely) png asset.


=== Xamarin Studio ===

Version 5.9.8 (build 0)
Installation UUID: 73e353b6-d62c-4087-83a0-cbff94bc27cb
Runtime:
	Mono 4.0.5 ((detached/1d8d582)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400050001

=== Xamarin.Android ===

Version: 5.1.9.0 (Indie Edition)
Android SDK: /Users/andrew/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.3   (API level 10)
		4.0.3 (API level 15)
		4.4   (API level 19)
		5.0   (API level 21)
		6.0   (API level 23)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)

=== Xamarin Android Player ===

Not Installed

=== Apple Developer Tools ===

Xcode 7.1 (9079)
Build 7B91b

=== Xamarin.iOS ===

Version: 9.1.0.27 (Indie Edition)
Hash: 1f068b4
Branch: master
Build date: 2015-10-27 18:59:21-0400

=== Xamarin.Mac ===

Not Installed

=== Build Information ===

Release ID: 509080000
Git revision: cc5f6e5658589ca7f46210c57fad947e75f30abd
Build date: 2015-10-21 19:27:41-04
Xamarin addins: d77f191bd7d3451adf837b85b38f2b7c60004400

=== Operating System ===

Mac OS X 10.10.5
Darwin ANDREW-PAGEs-5kiMac.local 14.5.0 Darwin Kernel Version 14.5.0
    Tue Sep  1 21:23:09 PDT 2015
    root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64