Ticket description causing "maximum recursion limit exceeded" in File "/usr/lib/python2.3/sre.py", line 143

[mcarpenter@…]

I have a ticket who's description is causing the timeline rss to die. To debug I added a line in "trac/wiki/formatter.py", line 686

        while old != result:
            old = result
+           self.env.log.error("%r %r %r" % (self._non_nested_block_re,
            result = re.sub(self._non_nested_block_re, simplify, old)

Attaching the log messages it generated.

[mcarpenter@…]

My trac.log from when the error occured with extra logging

[anonymous]

Oops, I see I only pasted in part of the line I added for the log file. Here's the full thing:

self.env.log.error("%r %r %r" % (self._non_nested_block_re, simplify, old,))

[cboos]

Hm, that would be my code :(

Thanks for the log, I was able to reproduce the issue.

[cboos]

(forgot to set the revision number in the source link)

[cboos]

Off-topic: Can someone tell me why, in the description above, the source link is rendered as trac/wiki/formatter.py", line 68, whereas the description source is:

[source:trunk/trac/wiki/formatter.py@2637#L684 "trac/wiki/formatter.py", line 686]

[markus]

cboos: I don't know why the last letter gets cut off, but shouldn't your link look like this?

[source:trunk/trac/wiki/formatter.py@2637#L684 "trac/wiki/formatter.py, line 684"]

[cboos]

Ah! I know. It's due to some buggy code of mine. In the Formatter._lhref_formatter:

        if target and target[0] in ("'",'"'):
            target = target[1:-1]

should be:

        if target and target[0] in ("'",'"') and target[0] == target[-1]:
            target = target[1:-1]

Sorry for the off-topic noise, I'll add the fix plus a new test case shortly.

[cboos]

Back to the original topic: the problem is with the following RE:

    _non_nested_block_re = re.compile(r"(?:^|\n)\{\{\{(?:\n(#![\w+-/]+))?"
                                      r"(?:\n([^{}]|\{(?!\{\{)|\}(?!\}\}))+)+"
                                      r"\}\}\}")

which simply crashes on some inputs (e.g. the string that can be found in the attached log). I guess it's because of the negative lookahead expressions.

Damn, it was already not easy to find a way to parse non nested {{{...}}} blocks, now I have to find another way...

[mgood]

cboos: also since "in" works on any iterable, you can use a string like so:

target[0] in "'\""

which I kind of like, although I don't know if other people find it confusing.

I also just noticed a kind of rare boundary condition where target is only one of the quote characters. In that case the link text will end up empty, though I think if people really want to do that, they can enclose the quote in other quotes.

[cboos]

The little problem with TracLinks discussed here was fixed in r2640 and r2641, while the main issue raised by this ticket was fixed in r2642.

If no further problem happen due to latter change, I'll port it to 0.9-stable in a few days and close this ticket.

[cboos]

The fix was ported to stable in r2657.