NetBSD Problem Report #46148

From tron@zhadum.org.uk  Tue Mar  6 17:22:14 2012
Return-Path: <tron@zhadum.org.uk>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 2443663E006
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  6 Mar 2012 17:22:14 +0000 (UTC)
Message-Id: <20120306172217.DEEA2A3BD3D@mail.zhadum.org.uk>
Date: Tue,  6 Mar 2012 17:22:17 +0000 (GMT)
From: tron@zhadum.org.uk
Reply-To: tron@zhadum.org.uk
To: gnats-bugs@gnats.NetBSD.org
Subject: cvs(1) broken in NetBSD 6.0_BETA
X-Send-Pr-Version: 3.95

>Number:         46148
>Category:       kern
>Synopsis:       tmpfs causes cvs corruption
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 06 17:25:00 +0000 2012
>Closed-Date:    
>Last-Modified:  Mon May 25 15:50:00 +0000 2015
>Originator:     Matthias Scheler
>Release:        NetBSD 6.0_BETA 2012-03-03 sources
>Organization:
Matthias Scheler                                  http://zhadum.org.uk/
>Environment:
System: NetBSD colwyn.zhadum.org.uk 6.0_BETA NetBSD 6.0_BETA (COLWYN.64) #0: Sat Mar 3 14:27:52 GMT 2012 tron@colwyn.zhadum.org.uk:/src/sys/compile/COLWYN.64 amd64
Architecture: x86_64
Machine: amd64
>Description:
I've got various problems with cvs(1) since I've upgraded my server to
NetBSD 6.0_BETA. As I use a local copy of the NetBSD CVS repository for
checkouts my best guess is that the server part is broken. CVS e.g.
crashed with this error message:

Mar  6 16:07:06  cvs: error (1, 0) called recursively.  Original message was:
Mar  6 16:07:06 colwyn cvs: cvs [checkout aborted]: flow control EOF 
Mar  6 16:07:06 colwyn cvs: error (1, 0) called recursively.  Second message was:
Mar  6 16:07:06 colwyn cvs: cvs [checkout aborted]: received broken pipe signal 
Mar  6 16:07:06 colwyn cvs: Aborting.

I've also seen it twice putting "xsrc" into a random sub directory of
"src" on checkout. Something is really wrong with the updated
cvs(1) in "netbsd-6".

>How-To-Repeat:
Create a local copy of the NetBSD CVS repository and try to check out
e.g. the "netbsd-4" branch with the following command:

cvs -q checkout -A -P -rnetbsd-4-0 src 

>Fix:
Not known.

>Release-Note:

>Audit-Trail:
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 12:52:34 -0500

 On Tue,  6 Mar 2012 17:25:01 +0000 (UTC)
 tron@zhadum.org.uk wrote:

 > I've also seen it twice putting "xsrc" into a random sub directory of
 > "src" on checkout. Something is really wrong with the updated
 > cvs(1) in "netbsd-6".

 I also use netbsd-6/amd64 since a few weeks.

 I didn't test the pserver yet on it, but I also use a local repository
 copy and am using it for checkout/updates, however I've not seen any
 similar issue so far.  Of course that doesn't mean no issue exists.

 It would be interesting to know if the odd file-mangling issue you
 experience still occurs with an older CVS...
 -- 
 Matt

From: Matthias Scheler <tron@zhadum.org.uk>
To: Matthew Mondor <mm_lists@pulsar-zone.net>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 17:59:46 +0000

 On Tue, Mar 06, 2012 at 05:55:02PM +0000, Matthew Mondor wrote:
 > The following reply was made to PR bin/46148; it has been noted by GNATS.
 > 
 > From: Matthew Mondor <mm_lists@pulsar-zone.net>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
 > Date: Tue, 6 Mar 2012 12:52:34 -0500
 > 
 >  On Tue,  6 Mar 2012 17:25:01 +0000 (UTC)
 >  tron@zhadum.org.uk wrote:
 >  
 >  > I've also seen it twice putting "xsrc" into a random sub directory of
 >  > "src" on checkout. Something is really wrong with the updated
 >  > cvs(1) in "netbsd-6".
 >  
 >  I also use netbsd-6/amd64 since a few weeks.
 >  
 >  I didn't test the pserver yet on it, but I also use a local repository
 >  copy and am using it for checkout/updates, however I've not seen any
 >  similar issue so far.  Of course that doesn't mean no issue exists.

 Did you try it with something as massive as NetBSD' repository?

 >  It would be interesting to know if the odd file-mangling issue you
 >  experience still occurs with an older CVS...

 I'm currently running a CVS checkout with a NetBSD 6.0_BETA binary on
 the client side and a NetBSD 5.1_STABLE binary on the server side.
 I'll report how that works out.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 13:46:45 -0500

 On Tue,  6 Mar 2012 18:00:07 +0000 (UTC)
 Matthias Scheler <tron@zhadum.org.uk> wrote:

 >  On Tue, Mar 06, 2012 at 05:55:02PM +0000, Matthew Mondor wrote:
 >  >  I didn't test the pserver yet on it, but I also use a local repository
 >  >  copy and am using it for checkout/updates, however I've not seen any
 >  >  similar issue so far.  Of course that doesn't mean no issue exists.
 >  
 >  Did you try it with something as massive as NetBSD' repository?

 That is one of the repositories, the largest and the most frequently
 used.
 -- 
 Matt

From: Matthias Scheler <tron@zhadum.org.uk>
To: Matthew Mondor <mm_lists@pulsar-zone.net>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 20:16:17 +0000

 On Tue, Mar 06, 2012 at 06:50:05PM +0000, Matthew Mondor wrote:
 >  >  On Tue, Mar 06, 2012 at 05:55:02PM +0000, Matthew Mondor wrote:
 >  >  >  I didn't test the pserver yet on it, but I also use a local repository
 >  >  >  copy and am using it for checkout/updates, however I've not seen any
 >  >  >  similar issue so far.  Of course that doesn't mean no issue exists.
 >  >  
 >  >  Did you try it with something as massive as NetBSD' repository?
 >  
 >  That is one of the repositories, the largest and the most frequently
 >  used.

 How do you access your repository? I'm accessing it via CVS over SSH.

 BTW: my checkout using a NetBSD 5.1_STABLE CVS binary on the server end
      works without any problems so far.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 15:30:06 -0500

 On Tue,  6 Mar 2012 20:20:04 +0000 (UTC)
 Matthias Scheler <tron@zhadum.org.uk> wrote:

 >  How do you access your repository? I'm accessing it via CVS over SSH.
 >  
 >  BTW: my checkout using a NetBSD 5.1_STABLE CVS binary on the server end
 >       works without any problems so far.

 My personal code repository is over SSH (to a netbsd-5/i386 server),
 although small compared to NetBSDs.  The NetBSD one used to be over
 NFS on the same server, but I moved the mirror to a local disk to gain
 speed lately.
 -- 
 Matt

From: Matthias Scheler <tron@zhadum.org.uk>
To: Matthew Mondor <mm_lists@pulsar-zone.net>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 21:59:15 +0000

 On Tue, Mar 06, 2012 at 08:35:01PM +0000, Matthew Mondor wrote:
 >  >  How do you access your repository? I'm accessing it via CVS over SSH.
 >  >  
 >  >  BTW: my checkout using a NetBSD 5.1_STABLE CVS binary on the server end
 >  >       works without any problems so far.
 >  
 >  My personal code repository is over SSH (to a netbsd-5/i386 server),

 Which won't reproduce the problem.

 >  although small compared to NetBSDs.  The NetBSD one used to be over
 >  NFS on the same server, but I moved the mirror to a local disk to gain
 >  speed lately.

 I assume that means you use something "cvs -d /what/ever/path" to access
 the repository. This will again not reproduce the problem.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 22:03:20 +0000

 On Tue, Mar 06, 2012 at 05:25:01PM +0000, gnats-admin@netbsd.org wrote:
 > Thank you very much for your problem report.
 > It has the internal identification `bin/46148'.
 > The individual assigned to look at your
 > report is: bin-bug-people. 
 > 
 > >Category:       bin
 > >Responsible:    bin-bug-people
 > >Synopsis:       cvs(1) broken in NetBSD 6.0_BETA
 > >Arrival-Date:   Tue Mar 06 17:25:00 +0000 2012

 I've retried checking out the "netbsd-4-0" branch sources (or in fact
 all currently supported NetBSD branches) with a NetBSD/amd64 5.1_STABLE
 "cvs" binary on the server side and a NetBSD/amd64 6.0_BETA "cvs" binary
 on the client side (OS is NetBSD/amd64 6.0_BETA on both ends). This
 setup works without problems.

 Considering this and the fact that I never had problems with a
 NetBSD 5.99.* or 6.99.* client when my server was still running
 NetBSD/amd 5.1_STABLE my conclusion is that "cvs server" mode
 is somehow broken in "netbsd-6" (and probably NetBSD-current).

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 17:53:14 -0500

 On Tue,  6 Mar 2012 22:05:03 +0000 (UTC)
 Matthias Scheler <tron@zhadum.org.uk> wrote:

 >  Considering this and the fact that I never had problems with a
 >  NetBSD 5.99.* or 6.99.* client when my server was still running
 >  NetBSD/amd 5.1_STABLE my conclusion is that "cvs server" mode
 >  is somehow broken in "netbsd-6" (and probably NetBSD-current).

 I also think only pserver server would matter at this point, unless the
 OP experiences another more general issue.  I also checked out a few
 repositories under CVS pserver (hosted on a netbsd-5 system) without
 issues.

 While trying to setup another pserver (this time on netbsd-6) I
 realized that it's been so long since the last time, and after two
 failed attempts I'd have to read some documentation, which I
 unfortunately can't do today.
 -- 
 Matt

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 18:42:26 -0500

 On Tue,  6 Mar 2012 22:55:02 +0000 (UTC)
 Matthew Mondor <mm_lists@pulsar-zone.net> wrote:

 >  While trying to setup another pserver (this time on netbsd-6) I
 >  realized that it's been so long since the last time, and after two
 >  failed attempts I'd have to read some documentation, which I
 >  unfortunately can't do today.

 Well, I did manage to get my CVS pserver auth working and initially
 checked out src to a tmpfs, which succeeded.  Then I tried with xsrc
 and the system crashed (no crash in /var/crash and ddb disabled,
 unfortunately).  Interestingly, yesterday I also managed to crash the
 system using tmpfs to build a full release.  The only other crash
 instance since I updated to netbsd-6 that was not related to tmpfs was
 when playing a movie from a cdrom mounted with rump (no issues when
 directly mounted).  Those are issues I'll have to eventually look
 deeper into (as well as find out why I cannot get kernel crash dumps).

 If doing src, xsrc, pkgsrc checkouts and updates from the
 netbsd-6/amd64 pserver to a non-tmpfs, it all seems to be successful
 and stable so far.  I'll leave a few automated checkout/update runs
 running and report again later.
 -- 
 Matt

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Tue, 6 Mar 2012 19:44:53 -0500

 On Tue,  6 Mar 2012 23:45:04 +0000 (UTC)
 Matthew Mondor <mm_lists@pulsar-zone.net> wrote:

 >  If doing src, xsrc, pkgsrc checkouts and updates from the
 >  netbsd-6/amd64 pserver to a non-tmpfs, it all seems to be successful
 >  and stable so far.  I'll leave a few automated checkout/update runs
 >  running and report again later.

 What the script did was cvs checkouts of src, xsrc of netbsd-3,
 netbsd-4-0, and  netbsd-current (no tags specified), over pserver.
 Then I ran find on some top-level files to make sure there were no such
 files randomly scattered in the tree (a very partial test), with no
 such occurances.  I would suspect that cvs update -dP would then reveal
 any serious inconsistency.

 So I ran a small script doing a cvs update -dP into the src and xsrc of
 the three trees.  I again checked for some top-level directory copies
 using find, with no results.

 So I ran a third small script which updated the netbsd-3 and netbsd-4-0
 src and xsrc trees also using -A, to trigger real updates.  Afterwards,
 a cvs -q update -dP still remained silent (no files to update, no
 abnormal files in the way).

 I'm sorry that I still couldn't reproduce what you're seeing, because
 if the issue isn't really in CVS, it's probably a more complex
 problem :(  It however was still worth the time, as if I had observed
 such CVS instability I would consider this PR critical.

 Is it certain that the repository you're checking out from has not been
 corrupted?  And that there are no known disk issue (none reported via
 atactl smart status either)?  What FS and mount options were you
 using?  This system uses FFSv2, mounted with log, noatime.
 -- 
 Matt

From: Matthias Scheler <tron@zhadum.org.uk>
To: Matthew Mondor <mm_lists@pulsar-zone.net>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Wed, 7 Mar 2012 07:55:50 +0000

 On Wed, Mar 07, 2012 at 12:45:02AM +0000, Matthew Mondor wrote:
 >  Is it certain that the repository you're checking out from has not been
 >  corrupted?

 Yes, because the NetBSD 5.1_STABLE CVS binary works *without any problems*.

 >  And that there are no known disk issue (none reported via
 >  atactl smart status either)?

 It is a RAIDframe RAID 1 and both disks are working fine.

 >  What FS and mount options were you  using?
 >  This system uses FFSv2, mounted with log, noatime.

 Same here. I've even forced file-system checks of the partition with
 the CVS repository and the partition with the source trees.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Matthias Scheler <tron@zhadum.org.uk>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Fri, 23 Mar 2012 08:25:44 +0000

 On Wed, Mar 07, 2012 at 08:00:09AM +0000, Matthias Scheler wrote:
 > The following reply was made to PR bin/46148; it has been noted by GNATS.
 > 
 > From: Matthias Scheler <tron@zhadum.org.uk>
 > To: Matthew Mondor <mm_lists@pulsar-zone.net>
 > Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
 > Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
 > Date: Wed, 7 Mar 2012 07:55:50 +0000
 > 
 >  On Wed, Mar 07, 2012 at 12:45:02AM +0000, Matthew Mondor wrote:
 >  >  Is it certain that the repository you're checking out from has not been
 >  >  corrupted?
 >  
 >  Yes, because the NetBSD 5.1_STABLE CVS binary works *without any problems*.

 I have to take that back. I suffered this problem even with a
 NetBSD 5.1_STABLE CVS binary on the server side.

 I've re-created my local CVS repository mirror in the meantime but
 that didn't fix the problem either.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Peter Kotcauer <int21h@pirosfeketefa.hu>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148
Date: Fri, 23 Mar 2012 11:38:59 +0100

 Hi All,

 I have a strange problem with cvs on NetBSD 6.0_BETA amd64.

 I've running the following commands (right after each other), as it can 
 be seen in the guide 
 (http://www.netbsd.org/docs/guide/en/chap-fetch.html#chap-fetch-cvs )

 #export CVS_RSH="ssh"
 #export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"

 #cd /usr
 #cvs checkout -r netbsd-6 -P src | tee checkout.log
 (you can find the output at: 
 http://pirosfeketefa.hu/netbsd/cvs/checkout.log )

 #cd src
 #cvs update -Pd &> ../update1.log
 #cvs update -Pd &> ../update2.log
 (you can find the outputs at: 
 http://pirosfeketefa.hu/netbsd/cvs/update1.log , 
 http://pirosfeketefa.hu/netbsd/cvs/update2.log ).

 #uname -a
 NetBSD  6.0_BETA NetBSD 6.0_BETA (GENERIC) amd64

 Thanks in advance,
 Peter

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148
Date: Fri, 23 Mar 2012 09:14:36 -0400

 On Fri, 23 Mar 2012 10:40:05 +0000 (UTC)
 Peter Kotcauer <int21h@pirosfeketefa.hu> wrote:

 >  #cd src
 >  #cvs update -Pd &> ../update1.log
 >  #cvs update -Pd &> ../update2.log
 >  (you can find the outputs at: 
 >  http://pirosfeketefa.hu/netbsd/cvs/update1.log , 
 >  http://pirosfeketefa.hu/netbsd/cvs/update2.log ).

 If updating using the -q (quiet) option, does it still display all
 those directories?  I have the impression that this is only verbose
 progress report...

 i.e.

 cvs -q update -dP &> ../update3.log

 Thanks,
 -- 
 Matt

From: Peter Kotcauer <int21h@pirosfeketefa.hu>
To: gnats-bugs@NetBSD.org
Cc: Matthew Mondor <mm_lists@pulsar-zone.net>, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org, tron@zhadum.org.uk
Subject: Re: bin/46148
Date: Fri, 23 Mar 2012 16:32:54 +0100

 On 03/23/2012 02:15 PM, Matthew Mondor wrote:
 > The following reply was made to PR bin/46148; it has been noted by GNATS.
 > 
 > From: Matthew Mondor <mm_lists@pulsar-zone.net>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: bin/46148
 > Date: Fri, 23 Mar 2012 09:14:36 -0400
 > 
 >  On Fri, 23 Mar 2012 10:40:05 +0000 (UTC)
 >  Peter Kotcauer <int21h@pirosfeketefa.hu> wrote:
 >  
 >  >  #cd src
 >  >  #cvs update -Pd &> ../update1.log
 >  >  #cvs update -Pd &> ../update2.log
 >  >  (you can find the outputs at: 
 >  >  http://pirosfeketefa.hu/netbsd/cvs/update1.log , 
 >  >  http://pirosfeketefa.hu/netbsd/cvs/update2.log ).
 >  
 >  If updating using the -q (quiet) option, does it still display all
 >  those directories?  I have the impression that this is only verbose
 >  progress report...
 >  
 >  i.e.
 >  
 >  cvs -q update -dP &> ../update3.log
 >  
 In this case does not display any directory.

 Sorry for messign up the thread.

 Regards,
 P

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Sat, 24 Mar 2012 00:44:33 -0400

 I have no idea yet if this could be related, and if so, in which
 situation this happens, but xcvs uses chdir(2) a lot, and I wonder if
 the cwd is always consistent.  It might be quick to assume a problem
 with chdir/cwd, but I noticed that on netbsd-6 with ff8 (I never had
 that problem with ff8 on netbsd-5), ff sometimes goes back to the
 previous-previous directory that was used to save a file rather than
 the previous one.  And gtkfilechooser does use chdir.  Of course, it
 also could be a bug in ff8 or gtk2...
 -- 
 Matt

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, tron@zhadum.org.uk
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Sat, 24 Mar 2012 17:41:31 +0000

 On Sat, Mar 24, 2012 at 04:45:02AM +0000, Matthew Mondor wrote:
  >  I have no idea yet if this could be related, and if so, in which
  >  situation this happens, but xcvs uses chdir(2) a lot, and I wonder if
  >  the cwd is always consistent.  It might be quick to assume a problem
  >  with chdir/cwd, but I noticed that on netbsd-6 with ff8 (I never had
  >  that problem with ff8 on netbsd-5), ff sometimes goes back to the
  >  previous-previous directory that was used to save a file rather than
  >  the previous one.  And gtkfilechooser does use chdir.  Of course, it
  >  also could be a bug in ff8 or gtk2...

 I find this highly improbable -- the current directory is a vnode
 reference saved in the process structure. If it were changing behind
 the process's back to some other vnode because of e.g. a refcounting
 or locking issue, it's highly unlikely you'd see specifically the
 previous-previous directory; you'd get some arbitrary directory or
 strange behavior because a regular file got picked up instead.
 Likewise for the chdir call retrieving and setting the wrong vnode.
 (And if the pointer were getting arbitrarily corrupted, you'd be
 seeing crashes.)

 It's much more likely that ff8 has a bug. It may not even be using the
 current directory as such to manage the state for that file-save
 dialog; I noticed with recent seamonkey that setting the cwd before
 starting the browser no longer initializes the default file save path
 for you.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Sat, 24 Mar 2012 15:24:14 -0400

 On Sat, 24 Mar 2012 17:45:03 +0000 (UTC)
 David Holland <dholland-bugs@netbsd.org> wrote:

 >  On Sat, Mar 24, 2012 at 04:45:02AM +0000, Matthew Mondor wrote:
 >   >  I have no idea yet if this could be related, and if so, in which
 >   >  situation this happens, but xcvs uses chdir(2) a lot, and I wonder if
 >   >  the cwd is always consistent.  It might be quick to assume a problem
 >   >  with chdir/cwd, but I noticed that on netbsd-6 with ff8 (I never had
 >   >  that problem with ff8 on netbsd-5), ff sometimes goes back to the
 >   >  previous-previous directory that was used to save a file rather than
 >   >  the previous one.  And gtkfilechooser does use chdir.  Of course, it
 >   >  also could be a bug in ff8 or gtk2...
 >  
 >  I find this highly improbable -- the current directory is a vnode
 >  reference saved in the process structure. If it were changing behind
 >  the process's back to some other vnode because of e.g. a refcounting
 >  or locking issue, it's highly unlikely you'd see specifically the
 >  previous-previous directory; you'd get some arbitrary directory or
 >  strange behavior because a regular file got picked up instead.
 >  Likewise for the chdir call retrieving and setting the wrong vnode.
 >  (And if the pointer were getting arbitrarily corrupted, you'd be
 >  seeing crashes.)

 You're probably right, yesterday I looked at the proc and lwp
 structures and there's no reason to think that it could remember the
 previous cwd (of course some shells can but that's irrelevant).  It
 could be that this ff8, spidermonkey or gtk2 bug only occurs on amd64,
 too, as I only briefly ran netbsd-5 on amd64, mostly on i386, and I
 didn't use netbsd-6 on i386 yet.
 -- 
 Matt

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Mon, 26 Mar 2012 17:39:00 +0000

 On Sat, Mar 24, 2012 at 07:25:02PM +0000, Matthew Mondor wrote:
  >  >  I find this highly improbable -- the current directory is a vnode
  >  >  reference saved in the process structure. If it were changing behind
  >  >  the process's back to some other vnode because of e.g. a refcounting
  >  >  or locking issue, it's highly unlikely you'd see specifically the
  >  >  previous-previous directory; you'd get some arbitrary directory or
  >  >  strange behavior because a regular file got picked up instead.
  >  >  Likewise for the chdir call retrieving and setting the wrong vnode.
  >  >  (And if the pointer were getting arbitrarily corrupted, you'd be
  >  >  seeing crashes.)
  >  
  >  You're probably right, yesterday I looked at the proc and lwp
  >  structures and there's no reason to think that it could remember the
  >  previous cwd (of course some shells can but that's irrelevant).  It
  >  could be that this ff8, spidermonkey or gtk2 bug only occurs on amd64,
  >  too, as I only briefly ran netbsd-5 on amd64, mostly on i386, and I
  >  didn't use netbsd-6 on i386 yet.

 Please file a separate PR on this... probably it will turn out to be
 an upstream issue.

 -- 
 David A. Holland
 dholland@netbsd.org

Responsible-Changed-From-To: bin-bug-people->kern-bug-people
Responsible-Changed-By: tron@NetBSD.org
Responsible-Changed-When: Sun, 08 Jul 2012 09:45:17 +0000
Responsible-Changed-Why:
I've tried a variety of CVS binaries (5.1.2, 6.0_BETA2, pkgsrc) and I kept getting
the exact same problem.

But after switching "/tmp" from tmpfs to mfs I hadn't had a single case of the
CVS corruption described in this bug.


From: Mindaugas Rasiukevicius <rmind@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: tron@NetBSD.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org, tron@zhadum.org.uk
Subject: Re: kern/46148 (tmpfs causes cvs corruption)
Date: Sun, 8 Jul 2012 12:46:46 +0100

 tron@NetBSD.org wrote:
 > Synopsis: tmpfs causes cvs corruption
 > 
 > Responsible-Changed-From-To: bin-bug-people->kern-bug-people
 > Responsible-Changed-By: tron@NetBSD.org
 > Responsible-Changed-When: Sun, 08 Jul 2012 09:45:17 +0000
 > Responsible-Changed-Why:
 > I've tried a variety of CVS binaries (5.1.2, 6.0_BETA2, pkgsrc) and I
 > kept getting the exact same problem.
 > 
 > But after switching "/tmp" from tmpfs to mfs I hadn't had a single case
 > of the CVS corruption described in this bug.

 Do you know some easy way (fewer steps/syscalls - better) to reproduce this
 corruption?  Can you ktrace when that happens?  We need more information on
 what is going on.

 -- 
 Mindaugas

From: Matthias Scheler <tron@NetBSD.org>
To: Mindaugas Rasiukevicius <rmind@netbsd.org>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/46148 (tmpfs causes cvs corruption)
Date: Sun, 8 Jul 2012 13:56:30 +0100

 On Sun, Jul 08, 2012 at 12:46:46PM +0100, Mindaugas Rasiukevicius wrote:
 > > Responsible-Changed-From-To: bin-bug-people->kern-bug-people
 > > Responsible-Changed-By: tron@NetBSD.org
 > > Responsible-Changed-When: Sun, 08 Jul 2012 09:45:17 +0000
 > > Responsible-Changed-Why:
 > > I've tried a variety of CVS binaries (5.1.2, 6.0_BETA2, pkgsrc) and I
 > > kept getting the exact same problem.
 > > 
 > > But after switching "/tmp" from tmpfs to mfs I hadn't had a single case
 > > of the CVS corruption described in this bug.
 > 
 > Do you know some easy way (fewer steps/syscalls - better) to reproduce this
 > corruption?

 No, unfortunately not.

 > Can you ktrace when that happens?

 I would have to revert my server (which I don't like reboot too much) to tmpfs.
 And the problem is that I don't know even whether it is the previous or the
 current run of "cvs" that suffers from the corruption.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

State-Changed-From-To: open->feedback
State-Changed-By: rmind@NetBSD.org
State-Changed-When: Thu, 05 Dec 2013 15:44:03 +0000
State-Changed-Why:
It is possible that this could have happened due to tmpfs readdir problems 
or perhaps a race condition -- both were recently fixed in -current.  Would
you like to upgrade and try to reproduce this again?

Otherwise, I think this PR should be closed.  There is nothing we can do
right now as there is no data to debug or even suspect where is the issue.
If you will experience something like that again - just fill a new PR.


From: Matthias Scheler <tron@zhadum.org.uk>
To: rmind@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/46148 (tmpfs causes cvs corruption)
Date: Thu, 5 Dec 2013 16:06:16 +0000

 On Thu, Dec 05, 2013 at 03:44:03PM +0000, rmind@NetBSD.org wrote:
 > Synopsis: tmpfs causes cvs corruption
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: rmind@NetBSD.org
 > State-Changed-When: Thu, 05 Dec 2013 15:44:03 +0000
 > State-Changed-Why:
 > It is possible that this could have happened due to tmpfs readdir problems 
 > or perhaps a race condition -- both were recently fixed in -current.  Would
 > you like to upgrade and try to reproduce this again?

 The machine in question is my server and runs NetBSD 6.1_STABLE. If somebody
 produces a patch for that release (which would be worthwhile IMHO) I'll
 happily test it.

 > Otherwise, I think this PR should be closed.  There is nothing we can do
 > right now as there is no data to debug or even suspect where is the issue.
 > If you will experience something like that again - just fill a new PR.

 That is fine with me as well. In that case I'll test "tmpfs" again once
 NetBSD 7.0_BETA becomes available.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

State-Changed-From-To: feedback->closed
State-Changed-By: rmind@NetBSD.org
State-Changed-When: Thu, 05 Dec 2013 17:37:51 +0000
State-Changed-Why:
Assume fixed (in -current).  If it appears again - fill a new PR.


State-Changed-From-To: closed->open
State-Changed-By: tron@NetBSD.org
State-Changed-When: Sat, 30 Aug 2014 08:41:11 +0000
State-Changed-Why:
I can still reproduce the problem on NetBSD/amd64 7.0_BETA on exactly the
same setup. I haven't see any corruption for month with MFS under 6.1_STABLE.

When I upgraded to 7.0_BETA and switched "/tmp" back to tmpfs the problem
started to happen again.

I'm using this kernel:

NetBSD colwyn.zhadum.org.uk 7.0_BETA NetBSD 7.0_BETA (GENERIC) #0: Wed Aug 20 13:44:09 BST 2014  tron@lyssa.zhadum.org.uk:/export/scratch/tron/obj/sys/arch/amd64/compile/GENERIC amd64


From: Matthias Scheler <tron@NetBSD.org>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: kern/46148 (tmpfs causes cvs corruption)
Date: Mon, 25 May 2015 09:42:42 +0100

 On Sat, Aug 30, 2014 at 08:41:11AM +0000, tron@NetBSD.org wrote:
 > Synopsis: tmpfs causes cvs corruption
 > 
 > State-Changed-From-To: closed->open
 > State-Changed-By: tron@NetBSD.org
 > State-Changed-When: Sat, 30 Aug 2014 08:41:11 +0000
 > State-Changed-Why:
 > I can still reproduce the problem on NetBSD/amd64 7.0_BETA on exactly the
 > same setup. I haven't see any corruption for month with MFS under 6.1_STABLE.
 > 
 > When I upgraded to 7.0_BETA and switched "/tmp" back to tmpfs the problem
 > started to happen again.
 > 
 > I'm using this kernel:
 > 
 > NetBSD colwyn.zhadum.org.uk 7.0_BETA NetBSD 7.0_BETA (GENERIC) #0: Wed Aug 20 13:44:09 BST 2014  tron@lyssa.zhadum.org.uk:/export/scratch/tron/obj/sys/arch/amd64/compile/GENERIC amd64

 I still can reproduce this problem with a NetBSD 7.99.18 GENERIC kernel.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Mindaugas Rasiukevicius <rmind@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: Matthias Scheler <tron@NetBSD.org>, kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, tron@zhadum.org.uk
Subject: Re: kern/46148 (tmpfs causes cvs corruption)
Date: Mon, 25 May 2015 15:11:57 +0100

 Hi Matthias,

 Matthias Scheler <tron@NetBSD.org> wrote:
 >  > State-Changed-From-To: closed->open
 >  > State-Changed-By: tron@NetBSD.org
 >  > State-Changed-When: Sat, 30 Aug 2014 08:41:11 +0000
 >  > State-Changed-Why:
 >  > I can still reproduce the problem on NetBSD/amd64 7.0_BETA on exactly
 >  > the same setup. I haven't see any corruption for month with MFS under
 >  > 6.1_STABLE.
 >  > 
 >  > When I upgraded to 7.0_BETA and switched "/tmp" back to tmpfs the
 >  > problem started to happen again.
 >  > 
 >  > I'm using this kernel:
 >  > 
 >  > NetBSD colwyn.zhadum.org.uk 7.0_BETA NetBSD 7.0_BETA (GENERIC) #0: Wed
 >  > Aug 20 13:44:09 BST 2014
 >  > tron@lyssa.zhadum.org.uk:/export/scratch/tron/obj/sys/arch/amd64/compile/GENERIC
 >  > amd64
 >  
 >  I still can reproduce this problem with a NetBSD 7.99.18 GENERIC kernel.
 >  

 More information is needed, e.g. trace what CVS is doing at the file
 system level or some other clue.  Alternatively, a quick and reliable
 way to reproduce it.  Otherwise, there is nothing we can do right now.

 -- 
 Mindaugas

From: Matthias Scheler <tron@NetBSD.org>
To: Mindaugas Rasiukevicius <rmind@netbsd.org>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/46148 (tmpfs causes cvs corruption)
Date: Mon, 25 May 2015 16:46:31 +0100

 On Mon, May 25, 2015 at 03:11:57PM +0100, Mindaugas Rasiukevicius wrote:
 > >  > NetBSD colwyn.zhadum.org.uk 7.0_BETA NetBSD 7.0_BETA (GENERIC) #0: Wed
 > >  > Aug 20 13:44:09 BST 2014
 > >  > tron@lyssa.zhadum.org.uk:/export/scratch/tron/obj/sys/arch/amd64/compile/GENERIC
 > >  > amd64
 > >  
 > >  I still can reproduce this problem with a NetBSD 7.99.18 GENERIC kernel.
 > >  
 > 
 > More information is needed, e.g. trace what CVS is doing at the file
 > system level or some other clue.  Alternatively, a quick and reliable
 > way to reproduce it.

 If I knew a quick and reliable way to reproduce this I would have mentioned
 this a long time ago.

 Unfortunately I don't. I only noticed the problem a few days after
 I move my local NetBSD CVS repository mirror from a machine with
 "/tmp" on MFS to a machine with "/tmp" on tmpfs.

 The best way I can suggest to reproduce it is creating a setup like
 my machine:
 1.) A mirror of NetBSD cvs repository on "/cvsroot".
 2.) tmpfs on "/tmp".
 3.) Checkout "src" over SSH from the local repository.
 4.) Once a day update "/cvsroot" via "rsync" then the update the
     check out with "cvs -q update -P d".

 Within less than a week you'll have a multiple copies of "src" in
 random subdirectories of "src".

 	Kind regards

 -- 
 Matthias Scheler                                 https://zhadum.org.uk/

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.