Can't edit (a specific) post without script freezing

Question

I'm trying to edit: BYTE to python C-Type structure Conversion Issue

However, every time I click on edit, Firefox (16.0.1 - Ubuntu 12.10) hangs for about 10 seconds, then prompts the usual "debug script", "stop script", "continue" - after hitting continue, it does appear to then present the data. I've not noticed this before on any other posts (and in fact can edit elsewhere fine), so just thought I'd raise it just in case. Screenshot attached of what the result is when attempting to do an edit.

Script name displayed is: http://cdn.sstatic.net/js/wmd.js?v=0360a509b7c2:4 (something to do with MarkDown perhaps?)

Answer 1

The code block for the test.py file contained a very long string literal

data="\x01\x00\x00\x00\x70\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02...

going on with some nonzero entries for a while, then ending in an estimated 80KB of \x00. All on one line.

That led to the parsing of the code block taking unusually long.

Answer 2

As mentioned, the issue here is catastrophic backtracking on that huge data string. I think addressing this in the general case may be a bit difficult (with the obvious solution being not to shove that much code into a single block), since unfortunately we're playing with fire here.

That said, in this particular scenario Markdown shoots itself in the foot a bit by rendering 4-space indented code blocks as

<pre><code>(code)
</code></pre>

which causes the subsequent recalling of HashHTMLBlocks to use the far less efficient "\n<tag> to </tag>\n" block matching regular expression.

If instead DoCodeBlocks performed the replacement as

codeblock = "<pre><code>" + codeblock + "</code>\n</pre>";
//                                       ^------^  shift newline

then HashHTMLBlocks would be able to make use of the first, more strict block matching expression, which, while still involving a lot of iterations, is significantly more efficient for cases like this.

Of course, unlike Chrome/Firefox/Opera, IE opts to display

<pre><code>(code)</code>
</pre>

incorrectly, preserving the newline between </code> and </pre>, so this may not be a viable solution.

There are some other, more complex changes that might be able to address this as well, but I'm not sure it makes sense to make drastic modifications for such an irrational edge case. Of course, the fact that this inconvenienced you as an editor going in to attempt to fix the problem(s) does make it seem a little more worthwhile from my perspective.

As a side note, I believe that the stricter expression can be modified to match in significantly fewer steps as well, by transforming

^(<(...)\b[^\r]*?\n<\/\2>[ \t]*(?=\n+))

into

^(<(...)\b([^\r\n]*\n)+?\n<\/\2>[ \t]*(?=\n+))

unless I'm mistaken and there's a reason they aren't functionally equivalent.

And actually, I think similar treatment can be applied to the looser expression as well (which would solve the general case reasonably) where

^(<(...)\b[^\r]*?.*<\/\2>[ \t]*(?=\n+)\n)

becomes

^(<(...)\b([^\r\n]*\n)*?[^\n]*<\/\2>[ \t]*(?=\n+)\n)

and completes against the generated <pre> element as-is in ~84,000 steps, versus the multiple millions currently required.