#2913: Memory Leak on SVN Repo Access using tracd or WSGI
---------------------------------------+------------------------------------
Reporter: edsuom | Owner: jonas
Type: defect | Status: new
Priority: high | Milestone: 0.10
Component: browser | Version: devel
Severity: major | Resolution:
Keywords: wsgi, tracd, memory, leak |
---------------------------------------+------------------------------------
Comment (by anonymous):
Found the source of the leak, finally. It appears in my installation when
Trac is forced to use enscript for source highlighting as a result of
exception handling. Now that I've got Trac working with SilverCity
''v0.9.5'' (annoyingly, ''v0.9.6''
[http://projects.edgewall.com/trac/wiki/TracFaq#why-is-my-css-code-not-
being-highlighted-even-though-i-have-silvercity-installed doesn't work]!),
there's no leak. Here's some pertinent IRC discussion on the topic. My
take on this is that the '''first''' exception caused by SilverCity either
being missing or choking due to the ''v0.9.6'' incompatibility (which
ought to have its own ticket if it doesn't already!) should set a flag
somewhere (perhaps a class attribute of the class that tried to run
SilverCity) to avoid trying to do that something again. If the sysadmin
fixes the environment so SilverCity will work, he will naturally expect to
have to restart the server in order to see if the change worked.
{{{
[11:22] <edsuom> cmlenz: You know the memory leak of mine?
[11:22] <cmlenz> yeah
[11:22] <edsuom> Try forcing your trac to use enscript instead of
silvercity and see what happens :-(
[11:24] <cmlenz> you're saying it has sth to do with the syntax coloring
mechanism?
[11:25] <edsuom> cmlenz: The "fix" for the leak for me was to get
silvercity working.
[11:25] <cmlenz> if that's the case, I'd suspect NaivePopen
[11:26] <-- [a]tomi has left this server ("optimizing...").
[11:26] <edsuom> cmlenz: I did some pretty elaborate gc tracking and saw
the svn pool stuff instances growing along with the exceptions caused by
silvercity.
[11:26] <edsuom> First it was the import exception, from it not being
there. Then it was the 2-tuple error, from 0.9.6. In both cases, it
leaked.
[11:27] <cmlenz> so you're seeing the leaks with a broken silvercity, not
with enscript?
[11:28] <cmlenz> weird that that would leak
[11:28] <edsuom> cmlenz: I was seeing the leak when trac was forced to use
enscript. Now that I've got it working with silvercity, there's no leak.
[11:28] <cmlenz> maybe something with references to pools in the traceback
[11:29] <cmlenz> ... creating a cycle
[11:29] <edsuom> cmlenz: That sounds like a good guess. I think the first
silvercity exception should make trac quit trying silvercity for
subsequent requests and just go to enscript.
[11:30] <edsuom> I don't think it's ever wise to rely on exception
handling as a routine part of your code's operation.
[11:30] <cmlenz> remembering something like that between requests adds
significant overhead, though
[11:31] <cmlenz> in python you often rely on importerrors etc to fallback
for optional dependenices
[11:31] <edsuom> cmlenz: I don't see why. Just use a class attribute
wherever the decision is being made to try silvercity.
[11:32] <cmlenz> so to use silvercity, the admin needs to restart the
server... I can see the tickets already :-P
[11:32] <edsuom> To *add* silvercity, you do. It's pretty widely expected
that you restart a server when you make changes to the guts of it.
[11:32] <pacopablo> eh, you have to restart the server for pretty much any
config cahnge anyway
[11:33] * inviso_ nods
[11:33] <cmlenz> pacopablo: that's not the intention, actually
[11:33] <cmlenz> changes to the server config, yes, but not changes to the
trac config
[11:33] <pacopablo> well no, but if you use just about anything other than
CGi that's the reality
[11:33] <inviso_> It's honestly not an unexpected thing though. Nothing
wrong with a server restart to bring in new modules. I'd do it anyway to
reload newer versions
[11:34] <edsuom> cmlenz: I'm not talking about config changes. I'm saying
that if the *environment* causes an exception when you try to do
something, it's good practice to set a flag to avoid trying to do that
something again. If you fix the environment, you restart the server.
[11:34] <cmlenz> probably the simplest solution would be to not even
register the SilverCity component if the import fails
[11:35] <edsuom> cmlenz: Sure, although the same leak problem happened
when it raised the exception about 2-tuple from silvercity 0.9.6.
[11:35] <cmlenz> gotta go... bbiab
[11:35] <-- cmlenz has left this server.
[11:37] <edsuom> I'm gonna copy this discussion to ticket #2913 and hope
that one of you guys picks it up...I've spent a *huge* amount of time
investigating it and someone can do the fixing.
}}}
--
Ticket URL: <http://projects.edgewall.com/trac/ticket/2913>
The Trac Project <http://trac.edgewall.com/>
_______________________________________________
Trac-Tickets mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-tickets
