Mylyn WikiText uses regular expressions to parse wiki markup. For Mylyn users, this means that your Bugzilla, JIRA and Trac bugs look good in the Eclipse UI. With the Galileo release of Eclipse, Mylyn WikiText added automatic stack trace detection.
Little did I know that the regular expression that I wrote would hang the Eclipse UI.

The intention was to format stack traces using a monospace font to improve layout:

Stack traces are detected by a regular expression. The regex that I created for this purpose worked well in testing, however for some stack traces would pin the CPU at near 100%, hanging the Eclipse UI. Here's what the regular expression looked like:

([A-Za-z][a-z0-9_$]*)+

Actually, the full regular expression is a lot bigger: 

\s*((((Caused by:\s+)|(at\s+))?([a-z][a-z0-9]*)(\.([a-z][a-z0-9]*))*\.([A-Za-z][a-z0-9_$]*)+((:\s+\w.*)|(\.((\)|([a-zA-Z0-9_$]+))\(.*?\)))?)|(\.\.\.\s\d+\smore))

The regex segment attempts to match a camel-case Java class name. What I didn't notice the first time around is that it contains nested greedy quantifiers. For some input can cause the CPU spiral of death... not good news.

To fix the offending regular expression is simple: just eliminate any nested quantifiers. My improved regular expression segment now looks like this:

[A-Za-z][a-zA-Z0-9_$]*

Two things that I learned from this experience:

  1. Never write a regular expression that nests greedy quantifiers.
  2. Always ensure that testing involves sufficient diversity of input data.