[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Have I got a corrupt repository?

From: Donald Sharp \(sharpd\)
Subject: RE: Have I got a corrupt repository?
Date: Wed, 14 Jan 2004 08:17:55 -0500

Andy -

As a suggestion to tackling this problem from a different direction,
would you please
run the check_cvs script over your repository.  The script should be
found in the scripts
directory of the cvs distribution.  I'm interested in the output.

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Mark D.
Sent: Wednesday, January 14, 2004 4:48 AM
To: Andy Jones
Cc: address@hidden
Subject: Re: Have I got a corrupt repository? 

Hash: SHA1

Andy Jones <address@hidden> writes:

> >What do you see in the CVS/Entries file for the corresponding 
> >directory that is showing those 'greek' filenames?
> Yep, you're right.  That's where the "greek filename" is coming from.

Okay. Now to try to figure out why the CVS/Entries file is getting
corrupted... the core dump is happening in the fprintf() that creates an
entry in that file...

> >That would be a matter of looking in bug tracking for your vendor 
> >(Redhat for version 7.1) to see if there were any bug reports against

> >the kernel you are using.
> Okay, I can't see anything, but that's not complete proof that you are

> wrong.

If you are at version 2.4.20-28.7 of the kernel and glibc-2.2.4-33, then
I doubt that there is an mmap bug around any longer. If you are not at
that level, you may wish to look into getting some updates from while they are still available.

> >The line in entries.c is this one:
> >    if (fprintf (fp, "/%s/%s/%s", p->user, p->version, p->timestamp) 
> >< 0) so it miht be interesting for you to issue the commands
> >
> >  up
> >  up
> >  p *p
> (gdb) up
> #1  0x40156677 in fprintf () from /lib/
> (gdb) up
> #2  0x0805d950 in fputentent (fp=0x82f7b40, p=0x80fbda0) at
> 424         if (fprintf (fp, "/%s/%s/%s", p->user, p->version,
p->timestamp) < 0)
> (gdb) p *p
> $1 = {type = 136248160, user = 0x80feec8 "\n\tim1", version = 
> 0x632f6c61 <Address 0x632f6c61 out of bounds>,

Well, a user value having a newline is not auspicious nor is having a
corrupt value for version and timestamp.

>   timestamp = 0x725f7376 <Address 0x725f7376 out of bounds>,
>   options = 0x736f7065 <Address 0x736f7065 out of bounds>,
>   tag = 0x726f7469 <Address 0x726f7469 out of bounds>, date =
0x61742f79 <Address 0x61742f79 out of bounds>,
>   conflict = 0x74736570 <Address 0x74736570 out of bounds>}
> Andy.

Trying to figure out how the values became corrupt is likely to be

        -- Mark

Version: GnuPG v1.2.3 (FreeBSD)


Info-cvs mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]