Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Michael Wojcik wrote:
> There is probably a bug in the CVSNT server, possibly a duplicate free,
> in some circumstances, which is triggering the automatic heap validation
> code in newer versions of glibc. (It's also possible that this is a bug
> in some library that CVSNT calls, or in glibc itself, though that's less
> likely.)
It's unlikely to be a duplicate free since the code is written to prevent that
- all pointers automatically get nulled at the end of the free... I don't
leave pointers hanging around.
Here is a segment of a run through passed valgrind - which is *much* more
strict than anything in gcc - showing no evidence of the bug. In fact if
finds a number of errors in libc (which is a free bug, but not at all cvsnt
related - IIRC libc has always had these issues).
The Windows version also does a lot of checking which would find any similar
problems.
I suspect then a bug in a related library, gcc or glibc itself.
Tony
---
-18:55:59-- http://www.google.ca/images/dot.gif
=> `dot.gif'
Resolving www.google.ca... 66.249.93.104, 66.249.93.99
Connecting to www.google.ca[66.249.93.104]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 46 [image/gif]
0K 100% 449.22 KB/s
18:56:02 (449.22 KB/s) - `dot.gif' saved [46/46]
cvsnt add: scheduling file `dot.gif' for addition
cvsnt add: use 'cvsnt commit' to add this file permanently
==13728== Invalid read of size 4
==13728== at 0x1BAED16C: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BAED58C: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BAED0B5: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BAFA6EC: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BAFB1F3: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BBE357C: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BBE36C4: __libc_freeres (in /lib/tls/libc-2.3.2.so)
==13728== by 0x1B8FEA08: _vgw(float, long double,...)(...)(long
double,...)(short) (vg_intercept.c:55)
==13728== by 0x1BB011C5: exit (in /lib/tls/libc-2.3.2.so)
==13728== by 0x1BAEB97D: __libc_start_main (in /lib/tls/libc-2.3.2.so)
==13728== by 0x804E7D0: ??? (start.S:102)
==13728== Address 0x1BC9F444 is 68 bytes inside a block of size 120 free'd
==13728== at 0x1B904B04: free (vg_replace_malloc.c:152)
==13728== by 0x1BAEDD37: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BBAC778: tdestroy (in /lib/tls/libc-2.3.2.so)
==13728== by 0x1BBE31C1: (within /lib/tls/libc-2.3.2.so)
==13728== by 0x1BBE36C4: __libc_freeres (in /lib/tls/libc-2.3.2.so)
==13728== by 0x1B8FEA08: _vgw(float, long double,...)(...)(long
double,...)(short) (vg_intercept.c:55)
==13728== by 0x1BB011C5: exit (in /lib/tls/libc-2.3.2.so)
==13728== by 0x1BAEB97D: __libc_start_main (in /lib/tls/libc-2.3.2.so)
==13728== by 0x804E7D0: ??? (start.S:102)
(this repeats for each cvs command).