java.lang.OutOfMemoryError

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • we are migrating our jobs to the multibranch pipelines, about a dozen or more. all of them work fine, but one repository wouldn't pass the branch indexing process. the process gets stuck and eventually fails with the following log message: {noformat} Setting origin to https://git..... Fetching origin... Finished: NOT_BUILT {noformat} after double and triple checking all our configurations and repositories, we couldn't find any difference between this repository and the others. I went through the Jenkins Log and found out that whenever this particular branch indexing fails the log prints out a java heap out of memory error. it doesn't show the full message on every such error, so I can only assume the first one of those is the relevant full stack trace: {noformat} Jun 08, 2016 11:31:22 AM SEVERE hudson.model.Executor finish1 Executor threw an exception java.lang.OutOfMemoryError: Java heap space at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:163) at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:118) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:610) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:587) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:550) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:507) at org.eclipse.jgit.internal.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:194) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:448) at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFetchConnection.java:762) at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:363) at org.eclipse.jgit.transport.TransportHttp$SmartHttpFetchConnection.doFetch(TransportHttp.java:783) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:301) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:291) at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:247) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:160) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.fetch(JGitAPIImpl.java:678) at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:174) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:146) at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:294) at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:157) at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:122) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) {noformat} again - we have no idea what makes the difference. the repository itself isn't bigger than the others, we don't have special characters in our branch names (only alphanomerics . - _ and such. no spaces and no escaped chars) and all the repositories are hosted in Assembla. running this same job as a regular pipeline job works. it's only the branch indexing that causes this problem. so my guess is that the heap space should be sufficient, but something somehow throws the indexing process into an infinite recursion (or something of the kind).
    via by Itai Sanders,
  • we are migrating our jobs to the multibranch pipelines, about a dozen or more. all of them work fine, but one repository wouldn't pass the branch indexing process. the process gets stuck and eventually fails with the following log message: {noformat} Setting origin to https://git..... Fetching origin... Finished: NOT_BUILT {noformat} after double and triple checking all our configurations and repositories, we couldn't find any difference between this repository and the others. I went through the Jenkins Log and found out that whenever this particular branch indexing fails the log prints out a java heap out of memory error. it doesn't show the full message on every such error, so I can only assume the first one of those is the relevant full stack trace: {noformat} Jun 08, 2016 11:31:22 AM SEVERE hudson.model.Executor finish1 Executor threw an exception java.lang.OutOfMemoryError: Java heap space at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:163) at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:118) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:610) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:587) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:550) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:507) at org.eclipse.jgit.internal.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:194) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:448) at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFetchConnection.java:762) at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:363) at org.eclipse.jgit.transport.TransportHttp$SmartHttpFetchConnection.doFetch(TransportHttp.java:783) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:301) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:291) at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:247) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:160) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.fetch(JGitAPIImpl.java:678) at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:174) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:146) at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:294) at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:157) at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:122) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) {noformat} again - we have no idea what makes the difference. the repository itself isn't bigger than the others, we don't have special characters in our branch names (only alphanomerics . - _ and such. no spaces and no escaped chars) and all the repositories are hosted in Assembla. running this same job as a regular pipeline job works. it's only the branch indexing that causes this problem. so my guess is that the heap space should be sufficient, but something somehow throws the indexing process into an infinite recursion (or something of the kind).
    via by Itai Sanders,
  • Stash checkout OutOfMemory
    via GitHub by kerrmarin
    ,
  • GitHub comment 27#103458058
    via GitHub by kerrmarin
    ,
  • out of memory while push a huge repo
    via by Vineel Nalla,
    • java.lang.OutOfMemoryError: Java heap space at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:163) at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:118) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:610) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:587) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:550) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:507) at org.eclipse.jgit.internal.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:194) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:448) at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFetchConnection.java:762) at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:363) at org.eclipse.jgit.transport.TransportHttp$SmartHttpFetchConnection.doFetch(TransportHttp.java:783) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:301) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:291) at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:247) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:160) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.fetch(JGitAPIImpl.java:678) at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:174) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:146) at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:294) at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:157) at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:122) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410)
    No Bugmate found.