Error reported by Rhodecode: 'maximum recursion depth exceeded'

Issue #642 resolved
Charles Lechasseur
created an issue

We got the following error report about 'maximum recursion depth exceeded' today. Sorry for the long text.

EDIT: that didn't go well :) I'll attach the callstack instead.

Comments (21)

  1. Marcin Kuzminski repo owner

    I have few questions on this issue: Do you use celery if yes, then did you verify it works properly and tasks are executed ? How may revisions that repository have, and what is your parse_limit size from the .ini file ?

  2. Peter Loron

    I'm also seeing this issue with one of our repos. We do not use celery. Rhodecode 1.5.1 + gunicorn. Ubuntu 12.04LTS server.

    Bare repo is ~73M in disk size. 3700 revisions. commit_parse_limit = 50.

  3. Marcin Kuzminski repo owner

    Is it reproducible ? The parsing function actually calls itself in a loop in recursive mode. Can you try increasing number of parsing changesets to 500 ?, and also check your python recursion limit, by doing python -c "import sys;print sys.getrecursionlimit()"

  4. Peter Loron

    Marcin, I checked and use_celery is set to false. Logging for most items is set to DEBUG. I've attached the error log I get in email when I try to view the Changelog for the repo.

  5. Marcin Kuzminski repo owner

    There's seems to be issue in dulwich library. I think the same error should happen when you browse changesets, and stumble accross the one that caused the recursion error.

    When you turn on debug loglevel you should see something like :

    2013-01-17 21:58:56.859 DEBUG [rhodecode.lib.celerylib.tasks] parsing <GitChangeset at 2602:36e78bd7acf0>
    2013-01-17 21:58:56.878 DEBUG [rhodecode.lib.celerylib.tasks] parsing <GitChangeset at 2603:3add79c071b3>
    2013-01-17 21:58:56.894 DEBUG [rhodecode.lib.celerylib.tasks] parsing <GitChangeset at 2604:bae3cfd18343>

    Last parsed changeset before recursion error should be also throwing issue when you try to see it changeset view.

    Would it be possible to check this ?

  6. Marcin Kuzminski repo owner

    Also would it be possible you edit dulwich code and get the value of base_offset from:

    type, base_chunks = self.resolve_object(base_offset, type, base_obj)

    code in dulwich ?

  7. Peter Loron

    I have these settings. Not quite sure what to change to get the level of output you're after:

    debug = true pdebug = false set debug = false use_celery = false

    When I change the config to be "set debug = true" I get immediate errors that the EvalException middleware is not available"

    Yes, I can edit the dulwich code. What's going to be the best way? Just doing a print to the console?

  8. Wolfgang Baron

    I have the same problem with rhodecode 1.6.0rc1 using celery when clicking on any changeset. Without celery, it seems to work.

    The stack is:

    Module rhodecode.controllers.changeset:256 in index
    >>  ignore_whitespace=ign_whitespace_lcl, context=context_lcl)
    Module rhodecode.lib.vcs.backends.hg.repository:260 in get_diff
    >>  context=context)))
    Module mercurial.extensions:189 in wrap
    >>  return wrapper(origfn, *args, **kwargs)
    Module hgext.keyword:629 in kw_diff
    >>  return orig(repo, node1, node2, match, changes, opts, prefix)
    Module mercurial.extensions:189 in wrap
    >>  return wrapper(origfn, *args, **kwargs)
    Module hgext.keyword:629 in kw_diff

    The last two frames repeat for ever.

    Now, that there are more users on the system, I could really use the celery speedup. Is there a workaround?

  9. Wolfgang Baron

    Yeah, sorry about the not quite perfect fit. I was unsure, whether I should start a new bug report. The title perfectly matches what I encountered. If you want a separate bug report for my case, I will gladly do so, I only don't know what to call it then. I get the "maximum recursion depth exceeded" when celery is being used and I click on a revision in the list of latest changes. Can you reproduce that, or do you need more information?

  10. Log in to comment