[cvsnt] cvs commit crashes with binary files

[Tony Hoyle]

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).