http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/find_recursionlimit.py?rev=HEAD&view=auto
But it needs a couple of changes to work for what we're trying to do. As written, it assumes that Python's default limit is safe, and only tests *higher* recursion limits. It also only tests the main thread, and the issue in bug 2653 was that non-main threads have less stack space available.
So, maybe someone with a Mac could run this script with a couple of modifications: first, changing it to run the tests in a thread, and second, to start with a lower initial recursion limit (say 100) and smaller steps (maybe 10?) in order to find out where the crash point is. The script is designed to output "Limit of 1000 is fine", "Limit of 1100 is fine", etc. until it crashes, so we would then have a measurement of what the limit should be set to on Mac OS X to prevent runaway recursion in a background thread from crashing Chandler. This would be especially helpful in the case of third-party packages that might contain hidden runaway recursion, as bug 2653 was caused by ZaoBao's feedparser module. With a safe memory limit, feedparser's behavior would not have caused any problems (which is why it worked on platforms where Python's default 1000 limit is safe).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
