on Tue Dec 30 2008, Christian Boos <cboos-AT-neuf.fr> wrote:
> David Abrahams wrote: >> on Sat Dec 27 2008, David Abrahams <dave-AT-boostpro.com> wrote: >> >> >>>> -On [20080617 22:20], David Abrahams ([email protected]) wrote: >>>> >>>>> #0 0x000000080098b85c in pthread_testcancel () from /lib/libpthread.so.2 >>>>> #1 0x0000000800982de7 in pthread_mutexattr_init () from >>>>> /lib/libpthread.so.2 >>>>> #2 0x00000008009849cb in pthread_mutexattr_init () from >>>>> /lib/libpthread.so.2 >>>>> #3 0x000000080098799f in pthread_setconcurrency () from >>>>> /lib/libpthread.so.2 >>>>> >>>> Last time I mentioned a possible threading/python issue on FreeBSD I got >>>> told on the Python list that FreeBSD's threading has caused issues for >>>> Python before. Now, whether or not this is a problem within FreeBSD or >>>> simply something else (read: Python itself), I cannot say. >>>> >>> Here's another stack backtrace of a Trac process taking 100% CPU. It's >>> a good thing the server has two cores ;-) >>> >>> I realize this seems to implicate FreeBSD threading, but this doesn't >>> happen to my Django processes, for example, so I'm still a little >>> inclined to suspect Trac. I have a hunch that these runaway processes >>> start when I ask for something that takes a long time from Trac, like an >>> old changeset, but then get impatient and cancel the request. Is that >>> possible? >>> >> >> In fact I can verify that viewing a changeset that touched approximately >> 2700 files sends CPU usage to 100% and that does not stop seemingly >> ever, until the webserver is restarted (which restarts the Trac >> processes). So that's a bug, yes? >> >> > > Well, you may just have hit some resource limits. What's the size of the > corresponding textual diff, to get an idea? I'm afraid I don't remember what commit I was looking at. I could try to reconstruct... OK, if I got the right diff set, "svn diff | wc -c" says it's precisely 11709506 bytes. > If it's in the 10Mb range, Yup. > that might well be too much for Trac and Genshi. I guess so! > Have a look at http://trac.edgewall.org/wiki/TracIni#changeset-section > and reduce the number of max. files (e.g. 500). Does the problem still > happen? Hmm, good question. svn diff -r 2791:2796 | grep -cE '^======================' says there are around 1929 files. OK, dropping the number to 500... ...works! > Now, on the hypothesis of an svn bindings bug, which version of the > bindings are you using? Versions >= 1.5.0 are supposed to fix a long > standing memory leak issue (see > http://trac.edgewall.org/ticket/6588#comment:3). Hum. We're on svn 1.5, but the 'svn' module doesn't have a __version__ attribute. The one in ports (FreeBSD) is py-subversion-1.5.4_2. I can't see why we'd have gone out of our way to install anything earlier than that. -- Dave Abrahams BoostPro Computing http://www.boostpro.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
