A Day of Bugfixing

Catastrophic Regexes

Today I learned that improperly defined regular expressions can behave similarly to an infinite loop. It’s not infinite - but runtime takes so long, and the program is unresponse that entire time - that it feels like it might as well be an infinite loop.

It has something to do with how regexes traverse a string. With a long enough string, the possibility space for determining whether it matches a regex can increase exponentially, leading to a very long search time.

Or something - I’m not sure that the description I gave is useful. I pesonally thought the issue was an infinite loop, and had gone through practically all of my loops before figuring out the issue (trying to use a /\\${(.|\s)*})/gm regex to detect template literals).

The general rule of thumb here is to avoid using both . and * (wildcard character, wildcard length) in the same expression of a regex, and to avoid complex logical ORs.

More information here: https://javascript.info/regexp-catastrophic-backtracking

eval-ing JS template literals with ${} in code tags

The template system that wanderer uses borrows JS template literals to do most of the heavy lifting; at its core, templates call eval() on the HTML template with the configuration as inserted values

However, this meant that writing ${} in a code example would cause serious problems, because the program would attempt to use it as a template literal, usually throwing exceptions since example code wasn’t meant to run.

The main solution I found to this was to escape all my $ symbols (by writing them as \$ in the source file). It’s not a terribly pretty solution, but will do in a pinch. The template parser unescapes them after all the rest of the processing is done.

true != “true”

This was an oversight on my part. Regardless of whether I’m using TOML or JSON or YAML, they would’ve all caused me to trip up about this.