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

    Yes, I can repro at will. I set the commit_parse_limit to 500, no change. The python recursion limit is 1000.

  5. Peter Loron

    This error also occurs for me when I run the search index generation on the same repo. I've run git fsck on the repo and it is clean.

  6. Marcin Kuzminski repo owner

    Hmm can you turn on the debug log levels maybe there is issue with parsing commits. Make sure celery_on flag is not turned on in ini config

  7. 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.

  8. Marcin Kuzminski repo owner

    I think i know what can be going on here, i'll update asap if i have something !

  9. 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 ?

  10. 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 ?

  11. 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?

  12. Marcin Kuzminski repo owner

    FIx for issue that was having Charles Lechasseur, is fixed now in beta branch, but Petere's issue is still not confirmed to be fixed

  13. 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?

  14. Marcin Kuzminski repo owner

    Hmm there was a patch somewhere for that, i'm certain it's in beta branch, i'll merge it to stable branch if it's not there.

  15. Marcin Kuzminski repo owner

    Scratch that off,patch was put in stable branch.

    @wrmbaron what do you mean by clicking on any changeset ? The original issue was only on summary page when statistics are generated in recursive mode

  16. 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?

  17. Marcin Kuzminski repo owner

    Yes if you can please open a new ticket, and please post whole traceback, important for me is to see the beginning of it.

  18. Log in to comment