Viewing 'Changeset' returns error "maximum recursion depth exceeded"

[jnorton@…]

When I click on the latest changeset, trac will pauses for about 20 seconds then return with

Oops...
Trac detected an internal error:

maximum recursion depth exceeded

This was working before although only with minor changes. The new changeset has quite a bit more changes but nothing that should break it, imo.

Pasted is the python traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/modpython_frontend.py", line 206, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/web_ui/changeset.py", line 86, in process_request
    self._render_html(req, repos, chgset, diff_options)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/web_ui/changeset.py", line 259, in _render_html
    ignore_space_changes='-b' in diff_options[1])
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/diff.py", line 179, in hdf_diff
    for group in _group_opcodes(opcodes, context):
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/diff.py", line 116, in _group_opcodes
    for idx, (tag, i1, i2, j1, j2) in enum(opcodes):
  File "/usr/lib/python2.3/site-packages/trac/util.py", line 37, in enum
    for item in iter(iterable):
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/diff.py", line 77, in _get_opcodes
    for tag, i1, i2, j1, j2 in matcher.get_opcodes():
  File "/usr/lib/python2.3/difflib.py", line 525, in get_opcodes
    for ai, bj, size in self.get_matching_blocks():
  File "/usr/lib/python2.3/difflib.py", line 473, in get_matching_blocks
    self.__helper(0, la, 0, lb, self.matching_blocks)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)
...{keeps repeating}
  File "/usr/lib/python2.3/difflib.py", line 490, in __helper
    self.__helper(i+k, ahi, j+k, bhi, answer)

Thanks in advance for the help and for a great application.

-Jerry

[mgood]

This is a duplicate of #2468 which was fixed for 0.9.3. Please try to upgrade to the latest stable version before filing new tickets.

[mgood]

Sorry, that's actually the wrong ticket. I've seen this mentioned before, though I can't find a ticket for it now. This is a problem with the standard Python difflib module when performing diffs on large files. I don't think there's anything Trac can do to fix this besides not trying to do diffs on large files.

However, please, please, please update your Trac to the latest version, especially since [milesonte:0.9.3] contains some security fixes.

[jnorton@…]

Thanks. I will upgrade as soon as I can.

What's considered large files? The biggest file that I changed was only 32kb and 1300 lines. It's pretty basic .php file. My goal was using this to compare changes made to website files. Is that a resonable expectation from the changeset feature?

[cboos]

Can you attach here the two versions of the files that you're trying to diff?

[cboos]

Sorry, but without adequate test data that would allow us
to reproduce the issue, we can't do much...

If someone sees this problem again, please reopen and
attach the two versions of the file that display the problem.

[PBruin]

I have the same problem and funny enouhg it is also on a php project.
However, this changeset is pretty big as somebody thought it was a great idea to do a lot of textual changes.

But, I think it is more likely some problem with php and changes in ' and "

I have just updated to the latest version of the trunk​

[cboos]

Replying to PBruin:

But, I think it is more likely some problem with php and changes in ' and "

Any chance you could post the two versions of the file involved?

[PBruin]

The problem is that there are many files that are changed. I was working on bringing dotproject under our own version control. In one of the last changes somebody edited about 108 files. Most of this is just re-aligning and changing bracket layout. Also some " -> ' changes. When I brought that into svn it caused this error.

Can you give me a hint how to find out which file it is that causes the problem?

[PBruin]

Just so you have a traceback of the current version:

Traceback (most recent call last):
  File "c:\python23\Lib\site-packages\trac\web\main.py", line 299, in dispatch_request
    dispatcher.dispatch(req)
  File "c:\python23\Lib\site-packages\trac\web\main.py", line 189, in dispatch
    resp = chosen_handler.process_request(req)
  File "c:\python23\Lib\site-packages\trac\versioncontrol\web_ui\changeset.py", line 246, in process_request
    diff_args, diff_options)
  File "c:\python23\Lib\site-packages\trac\versioncontrol\web_ui\changeset.py", line 491, in _render_html
    diffs = _content_changes(old_node, new_node)
  File "c:\python23\Lib\site-packages\trac\versioncontrol\web_ui\changeset.py", line 463, in _content_changes
    ignore_space_changes='-b' in options)
  File "c:\python23\Lib\site-packages\trac\versioncontrol\diff.py", line 177, in hdf_diff
    for group in _group_opcodes(opcodes, context):
  File "c:\python23\Lib\site-packages\trac\versioncontrol\diff.py", line 114, in _group_opcodes
    for idx, (tag, i1, i2, j1, j2) in enumerate(opcodes):
  File "c:\python23\Lib\site-packages\trac\versioncontrol\diff.py", line 75, in _get_opcodes
    for tag, i1, i2, j1, j2 in matcher.get_opcodes():
  File "C:\Python23\Lib\difflib.py", line 525, in get_opcodes
    for ai, bj, size in self.get_matching_blocks():
  File "C:\Python23\Lib\difflib.py", line 473, in get_matching_blocks
    self.__helper(0, la, 0, lb, self.matching_blocks)
  File "C:\Python23\Lib\difflib.py", line 490, in __helper
  etc.
  etc.
  etc.....

[cboos]

Replying to PBruin:

Can you give me a hint how to find out which file it is that causes the problem?

Setup your TracIni like this:

[changeset]
max_diff_files = 1

Then view the faulty changeset. You should now have 108 links to restricted changesets, one for each file. Then... go through all of them to find the guilty one(s) (a browser which support tabbed browsing is a plus, or maybe use wget on this page, or just be patient ;) )

[PBruin]

These files are identical but somehow differ in size?!? 134KB compared to 138KB. Don't have a clue why as the are copies from the cvs of dotproject...

[anonymous]

Smallest file

[anonymous]

This one has a lot of 0x0D's added when I check with bin compare

[mgood]

Replying to PBruin:

These files are identical but somehow differ in size?!? 134KB compared to 138KB. Don't have a clue why as the are copies from the cvs of dotproject...

nusoap12.php has Unix line ends and nusoap15.2.php has Windows line ends.

I don't think there's a way to actually "fix" the recursion depth issue, since it's a symptom of the Python difflib module. I think the best that can be done here is to try to catch the exception and display an error message in place of that file's diff.

[cboos]

I confirm that with the attached files, one can reproduce the issue.
However, my attempts to create a smaller test case were unsuccessful so far
(e.g. comparing line range [392:3000] triggers the error, but not comparing the [393:3000] range nor the [392:2999] one).

As those files differ only in their amount of end-of-lines characters, there are lots of similar lines at different offsets, so the algorithm for finding similar lines is certainly pushed to some corner case.

So I agree with mgood, we should at least trap that error after the fact when it happens.

[cboos]

#3661 marked as duplicate.
I also wonder if we shouldn't do some kind of line ending normalization before handing over the two contents to difflib, if "ignore white-space changes" is checked.

[anonymous]

FYI this is due to a bug reported in python (​tracker item 1413711). The fix is included in python2.5. For python2.4, copying difflib.py from the standard library to a location that is ahead of it on sys.path and applying the patch attached to the bug report has worked for us.

[cboos]

Thanks a lot anonymous!

This issue was even more painful with Trac 0.11dev in the admin mode of error reporting, as the locals for each frame of this huge stack trace were included in the page...

Now, for the problematic files (e.g. those attached in this ticket), the problem has shifted from Trac (which doesn't crash anymore once difflib.py is patched) to the browser...

• Firefox 2.0.0.1 (win32) eats 100% of the CPU and remains unresponsive
• Opera triggers some socket errors ('Software caused connection abort')
• IExplorer7 is here the winner ;) The display is dog slow, but at least the content is there!

What is strange is that the generated HTML is not that huge (1,908,389 bytes).

[cboos]

So this was ​PythonBug:1413711.

I'm not sure that we now correctly trap the error for Python 2.4, this needs to be verified again.

[cboos]

Closed #9684 as duplicate. It was reported for a 0.10.4 version, so we still don't know by this if we correctly trap the error. Looking at the corresponding Python bug, this was fixed in r42212 and at that time 2.4.2 was the latest released Python version, so I suppose the fix made it for 2.4.3.

Anyway, as Python 2.4 is no longer supported in trunk, and given we didn't have that many reports for this issue, I'd say better let it die and close as wontfix.

[cboos]

(if someone cares enough for reopening, then please do the required testing and provide a patch; if not, there's no point in reopening)