PMD runs endlessly on some generated files

A source code analyzer

Brought to you by: adangel, juansotuyo

#1308 PMD runs endlessly on some generated files

Milestone: PMD-5.3.0

Status: closed

Owner: Andreas Dangel

Labels: None

Module: PMD

Priority: 3-Major

Type: Bug

Affects version: 5.1.2, 5.2.3

Ruleset / Rule:

Updated: 2015-04-01

Created: 2015-01-16

Creator: Boris Baldassari

Private: No

PMD runs endlessly on some Java files, taking 100% CPU. After several hours, the output is still empty. Two example files that reproduce it systematically are attached.

Both files have in common a huge list of 'public static final BitSet' declarations at their end (roughly 850+). Removing half of it makes PMD finish the run.

I tried it with Oracle Java 1.8.0_25, and 1.8.0_11 on Linux Mint, and OpendJDK 1.7.0_51 on Suse (all 64bits).

I tried setting $ export HEAPSIZE=4096m to make sure it was not a xmx problem, but no luck either.

I could reproduce it with PMD 5.1.2 and 5.2.3.

2 Attachments

InternalDataParser.java

InternalVpdiagramParser.java

Discussion

Boris Baldassari - 2015-01-20

Did more tests:

Could reproduce it on the 5.3.0 HEAD (#5ae01d2 5.3.0-SNAPSHOT).

Bug is in java-design (removing it allows pmd to finish, even if the analysis is quite long for a single file).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andreas Dangel - 2015-01-28

status: open --> closed

assigned_to: Andreas Dangel

Milestone: New Tickets --> PMD-Next
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andreas Dangel - 2015-01-28

Thanks for reporting this issue. I could apply overall performance improvements which brought the runtime from more than 3 hours (didn't want to wait longer) down to 3 minutes (the complete design ruleset). After that, I saw, that the rule FieldDeclarationsShouldBeAtStartOfClass was the slowest one. I ended up rewriting this rule from XPath to a Java rule. This brought the runtime down to less than 30 seconds for the design ruleset.

The underlaying issue is probably, that these classes are huge - they have many, many class-level elements like methods and fields.

This fix will be included with the next release.

Your build time should already improve drastically by excluding this single rule via a custom ruleset, e.g.

<?xml version="1.0"?> <ruleset name="ExampleRuleset" xmlns="http://pmd.sourceforge.net/ruleset/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd"> <description> Design without FieldDeclarationsShouldBeAtStartOfClass </description> <rule ref="rulesets/java/design.xml"> <exclude name="FieldDeclarationsShouldBeAtStartOfClass" /> </rule> </ruleset>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Boris Baldassari - 2015-01-29

Hi Andreas,

I can confirm both the bug fix and the performance improvement. This is quite impressive:

boris@castalia$ time ~/applis/pmd-bin-5.2.3/bin/run.sh pmd -f xml -rulesets myrules.xml -r myout.xml -d kitalpha/ real 0m46.796s user 1m12.964s sys 0m4.193s boris@castalia$ time ~/applis/pmd-current/bin/run.sh pmd -f xml -rulesets myrules.xml -r myout.xml -d kitalpha/ real 0m33.100s user 1m7.192s sys 0m1.922s

Thanks for your work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.