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? -- 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 -~----------~----~----~----~------~----~------~--~---
