Diagnosing Errors

This page provides guidelines about diagnosing the most common types of errors you may see when using Jenkins.

Out Of Memory Errors

OutOfMemoryErrorerrors may happen for many different reasons:

  • Your Jenkins is growing in data size, requiring a bigger heap space. In this case you just want to give it a bigger heap.

  • Your Jenkins is temporarily processing a large amount of data (like test reports), requiring a bigger head room in memory. In this case you just want to give it a bigger heap.

  • Your Jenkins is leaking memory, in which case we need to fix that.

  • The Operating System kernel is running out of virtual memory.

Which category yourOutOfMemoryErrorfalls into is not always obvious, but here are a few useful techniques to diagnose the problem.

  • UseVisualVM, attach to the running instance, and observe the memory usage. Does the memory max out while loading Jenkins? If so, it probably just needs a bigger memory space. Or is it slowing creeping up? If so, maybe it is a memory leak.

  • Do you consistently seeOutOfMemoryError大约在同一阶段构建?如果是这样,也许just needs a bigger memory.

  • In cases where virtual memory is running short the kernelOutOfMemoryErrorkiller may forcibly kill Jenkins or individual builds. If this occurs on Linux you may see builds terminate with exit code137(128+ signal number forSIGKILL). Thedmesgcommand output will show log messages that will confirm the action that the kernel took.

If you think it’s a memory leak, the Jenkins team needs to get the heap dump to be able to fix the problem. There are several ways to go about this.

  • Run JVM with-XX:+HeapDumpOnOutOfMemoryErrorso that JVM will automatically produce a heap dump when it hitsOutOfMemoryError.

  • You can runjmap -dump:live,file=/tmp/jenkins.hprof pidwhere pid is the process ID of the target Java process.

  • UseVisualVM, attach to the running instance, and obtain a heap dump

  • If your Jenkins runs athttp://server/jenkins/, requesthttp://server/jenkins/heapDumpwith your browser and you’ll get the heap dump downloaded.

  • If you are familiar with one of many Java profilers, they normally offer this capability, too.

Once you obtain the heap dump, please post it somewhere, then open an issue (or look for a duplicate issue), and attach a pointer to it. Please be aware that heap dumps may contain confidential information of various sorts.

If the full heap dump is too big, please try to get us the heap histogram (jmap -histo:live pid).

In the past, the distributed build support has often been a source of leakage (as this involves in a distributed garbage collection.) To check for this possibility, visit links likehttp://yourserver/jenkins/computer/YOURAGENTNAME/dumpExportTable. If this show too many objects, they may be leaks.

Analyzing the heap dump yourself

If you cannot let us inspect your heap dump, we need to ask you to diagnose the leak.

  • First, find the objects with biggest retention size. Often they are various Maps, arrays, or buffers.

  • Next, find the path from that object to GC root, so that you can see which Jenkins object owns those big objects.

Report the summary of those findings to the list and we’ll take it from there.

Using VisualVM

Unless you already have a preferred memory profiling tool, VisualVM is recommended for analyzing heap dumps. It is a standalone version of the NetBeans profiler, distributed with the Oracle JDK.

Runjvisualvmand useFile » Loadand select the heap dump. In theClassestab, look for a class with a suspiciously large number of instances, if not already identified byjmap -histo. For example, to debug a Groovy script leak, typeGroovyClassLoaderin the filter field and double-click the line with no$in it (justgroovy.lang.GroovyClassLoader).

In theInstancestab you should now see all instances. Click on some at random. (If there are more than 500, they will be broken into groups of 500, with the first expanded; so to get a representative instance "from the middle", collapse the first group, expand a group in the middle, and select some instance from that group.)

UnderReferences, right-clickthisand selectShow Nearest GC Root. Right-click the selected item in the tree and selectCopy Path From Root. Paste this text, for several examples, into a text file and attach it to a bug report—or continue your investigation into plugin source code.

How to Report a Bug

For easier bug reporting, you can get the full list of plugins with this Groovy script that you can run inJenkins > Manage Jenkins > Script Console:

println("Jenkins: ${Jenkins.instance.getVersion()}") println("OS: ${System.getProperty('os.name')} - ${System.getProperty('os.version')}") println "---" Jenkins.instance.pluginManager.plugins .collect() .sort { it.getShortName() } .each { plugin -> println("${plugin.getShortName()}:${plugin.getVersion()}") } return

Was this page helpful?

Please submit your feedback about this page through thisquick form.

Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?

See existing feedbackhere.