zope recursion during build / test / install

[nejucomo]

I left my machine while running "time { python setup.py build && python setup.py test && python setup.py install; }". I ran this inside of a "cd /media/target-disk; chroot ." on a debian system, even though /media/target-disk contains an ubuntu installation!

When I returned the command output ended with:

  File "/usr/local/src/allmydata-tahoe-1.5.0/zope.interface-3.5.2-py2.5-linux-x86_64.egg/zope/interface/declarations.py", line 1370, in _normalizeargs
    _normalizeargs(v, output)
  File "/usr/local/src/allmydata-tahoe-1.5.0/zope.interface-3.5.2-py2.5-linux-x86_64.egg/zope/interface/declarations.py", line 1370, in _normalizeargs
    _normalizeargs(v, output)
  File "/usr/local/src/allmydata-tahoe-1.5.0/zope.interface-3.5.2-py2.5-linux-x86_64.egg/zope/interface/declarations.py", line 1366, in _normalizeargs
    if InterfaceClass in cls.__mro__ or Implements in cls.__mro__:
RuntimeError: maximum recursion depth exceeded in cmp

Unfortunately I cannot scroll back to see the top of the stack trace or more relevant logs.

When I rerun the same command, unit tests seem to begin executing until they abort strangely with a different error which I will file as a separate ticket.

[zooko]

I've been doing some googling and found this: ​https://bugs.launchpad.net/zope3/+bug/113672 (passing a string into zope.interface.implements causes infinite recursion). Not sure if this is related to our issue.

[zooko]

I talked to nejucomo and the "strangely with a different error which I will file as a separate ticket" turned out to be due to the lack of a /proc in the chroot.

    test_loadable ...                                                      [OK]
    test_reloadable ... Node._startService failed, aborting
[Failure instance: Traceback (failure with no frames): <class 'twisted.internet.utils._UnexpectedErrorOutput'>: got stderr: 'Warning: cannot open /proc/net/dev (No such file or directory). Limited output.\n'
]
calling os.abort()
Aborted

[davidsarah]

A similar problem seems to be happening on Dcoder's Win7 buildslave: ​http://tahoe-lafs.org/buildbot/builders/Dcoder%20Win7-64%20py2.6/builds/35/steps/test/logs/stdio

[davidsarah]

Also see ​this message from March 2009.

[sneves]

Replying to davidsarah:

A similar problem seems to be happening on Dcoder's Win7 buildslave: ​http://tahoe-lafs.org/buildbot/builders/Dcoder%20Win7-64%20py2.6/builds/35/steps/test/logs/stdio

Apparently this was the result of a faulty build (I built zope interface from the source using setup.py install). Using the binary egg from ​http://pypi.python.org/pypi/zope.interface#download seemed to solve this issue.

[daira]

I haven't seen this for a while; I assume it has been fixed in more recent versions of zope.interface, and/or was only a problem for faulty builds.