On Dec 27, 7:52 am, Larry Jones <lawrence.jo...@siemens.com> wrote: > > I than ran CVS with valgrind, and it produced the following output for > > checkout of a ~15 MB big CVS tree with 1539 files: > [...] > > The one problem that stands out here is the last one: >5MB allocated, > > still reachable, but in a place that seems to make no sense. It is in > > main(), in the allocation of program_path. > > Indeed, that makes no sense at all. However, the line numbers in your > valgrind output don't match up with the line numbers in the official CVS > 1.12.13 source, so either valgrind is reporting them incorrectly or you > are running some version of CVS other than 1.12.13 (or a modified > version of 1.12.13). Without knowing exactly what version you're > running, it's hard to say anything about what's going on.
Hello Larry, Thanks for replying. You're right - we use a modified version of 1.12.13 on that server - see my previous posts regarding soft-tags and persistent modules. Apparently I used the wrong CVS executable in my test. To be 100% sure I downloaded again the original CVS 1.12.13 source code from http://ftp.gnu.org/non-gnu/cvs, built it, and ran my test again. The same problem happened again, and this time the line number in main.c was 552 - and again it is the program_path Xstrdup() call. Unless something is deeply wrong with my installation of valgrind (which I doubt - it works fine for me with other programs I maintain), there is indeed a problem here. Bypassing it by avoiding use of mmap is not really going to help, only delay the time when the virtual memory is exhausted and some other memory allocation is going to fail. I would appreciate it if you (or another maintainer) could at least make a quick check with valgrind to verify that there is really a problem here, so I'll know I'm not just hallucinating. Thanks again, Yaron _______________________________________________ Bug-cvs mailing list Bug-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-cvs
