Re: Have I got a corrupt repository?

[Andy Jones]

>And you are sure that there are no 'odd' files present in your
>repository? (ls -alR) I think Redhat Linux allows UTF-8 characters in
>filenames...

I'm afraid so.  I did try an "ls -b" at the time; and wiping the sandbox and 
recopying from my original tar made the problem go away.

>Define 'large commit' please. Many files? Many LARGE files? A few LARGE
>files? It almost sounds like mmap() is broken on your system.

About 200 files were committed according to the log (although I guess that's 
not a guaranteed number if CVS crashed half way).  Sounds about right, though.  
Your average file should be about 5k.

I don't know what mmap() does or how to tell if it is broken.  Your suggestion 
is filed to try later, and thank you, although at the moment I have a baseline 
release to get out....

>What do you see in the CVS/Entries file for the corresponding directory
>that is showing those 'greek' filenames?

I may be able to duplicate the problem tomorrow, and if so, I'll find out and 
post again.

>Use 'top' to see what memory and sap you have free on your system.

::slaps heel of hand against forehead:: of course.  ....Swap file working fine 
and 500Mb as advertised.

>Crashing in a malloc() to obtain 39 bytes is a bad sign. You really need
>to see how much free memory and swap you have on your system.

You might be interested to see another trace from a different core:
===============================
(gdb) bt
#0  0x4014e1c6 in vfprintf () from /lib/libc.so.6
#1  0x40156677 in fprintf () from /lib/libc.so.6
#2  0x0805d950 in fputentent (fp=0x82f7b40, p=0x80fbda0) at entries.c:424
#3  0x0805d1ce in write_ent_proc (node=0x80fdd48, closure=0xbffff5f0) at 
entries.c:100
#4  0x0806213a in walklist (list=0x80fe870, proc=0x805d1a0 <write_ent_proc>, 
closure=0xbffff5f0) at hash.c:370
#5  0x0805d268 in write_entries (list=0x80fe870) at entries.c:140
#6  0x0805dcb5 in Entries_Close (list=0x80fe870) at entries.c:580
#7  0x0807d642 in do_recursion (frame=0xbffff6f0) at recurse.c:793
#8  0x0807dcdb in do_dir_proc (p=0x80d35d8, closure=0xbffff798) at 
recurse.c:1134
#9  0x0806213a in walklist (list=0x80d3fb8, proc=0x807d77c <do_dir_proc>, 
closure=0xbffff798) at hash.c:370
#10 0x0807d61c in do_recursion (frame=0xbffff830) at recurse.c:783
#11 0x0807d0b6 in start_recursion (fileproc=0x80587e0 <commit_fileproc>,
    filesdoneproc=0x8058c58 <commit_filesdoneproc>, direntproc=0x8058dd4 
<commit_direntproc>,
    dirleaveproc=0x8058e90 <commit_dirleaveproc>, callerdat=0x0, argc=0, 
argv=0x82ac150, local=0, which=1,
    aflag=0, locktype=0, update_preload=0x0, dosrcs=1, repository_in=0x0) at 
recurse.c:366
#12 0x08057ed1 in commit (argc=3, argv=0x80d31b4) at commit.c:679
#13 0x0806d82d in main (argc=3, argv=0x80d31a8) at main.c:994
#14 0x40113237 in __libc_start_main () from /lib/libc.so.6
================================

The common denominator seems to be walklist() although I guess if it's just a 
case of running out of resources, then that doesn't mean much.

Thanks again and hopfully I'll post tomorrow

Andy.