On 5/22/06, Linus Torvalds <torvalds@osdl.org> wrote: > Did you do a "top" at any time just before this all happened? It _sounds_ > like it might actually be a memory leak on the CVS server side, and the > problem may (or may not) be due to the optimization that keeps a single > long-running CVS server instance for the whole process. Running a few tests right now. Looks like cvs (Debian/etch 1.12.9-13) itself is not leaking any memory. The Perl (Debian/etch 5.8.7-something and now 5.8.8-4) process OTOH is visibly allocating memory. Starts off at 4MB and gets up to ~17MB by the time it has done 6K commits. I am trying to figure out whether the leak is in the script or in the Perl implementation, using PadWalk, Devel::Leak and friends. If the leak is here, I can't see it (yet). > I wouldn't be in the least surprised if that ends up triggering a slow > leak in CVS itself, and then CVS runs out of memory. Or a slow leak in Perl? The 5.8.8 release notes do talk about some leaks being fixed, but this 5.8.8 isn't making a difference. Working on it. martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Mon May 22 17:42:46 2006
This archive was generated by hypermail 2.1.8 : 2006-05-22 17:43:05 EST