Re: kern/43240 (KASSERT umap->refcount != 0 failed (sys/uvm/uvm_bio.c:248))

[Nicolas Joly <njoly%pasteur.fr@localhost>]

The following reply was made to PR kern/43240; it has been noted by GNATS.

From: Nicolas Joly <njoly%pasteur.fr@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: chs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost,
        gnats-admin%netbsd.org@localhost, njoly%pasteur.fr@localhost
Subject: Re: kern/43240 (KASSERT umap->refcount != 0 failed 
(sys/uvm/uvm_bio.c:248))
Date: Mon, 19 Mar 2012 17:02:04 +0100

 On Sun, Mar 18, 2012 at 02:08:04AM +0000, chs%NetBSD.org@localhost wrote:
 > Synopsis: KASSERT umap->refcount != 0 failed (sys/uvm/uvm_bio.c:248)
 > 
 > Responsible-Changed-From-To: kern-bug-people->chs
 > Responsible-Changed-By: chs%NetBSD.org@localhost
 > Responsible-Changed-When: Sun, 18 Mar 2012 02:08:02 +0000
 > Responsible-Changed-Why:
 > I'm looking at this.
 > 
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: chs%NetBSD.org@localhost
 > State-Changed-When: Sun, 18 Mar 2012 02:08:02 +0000
 > State-Changed-Why:
 > I tried this to a netbsd/amd64 box running 6.0_BETA but it didn't crash:
 > 
 > $ cat /dev/zero | rsh nbsd-amd64 dd of=/dev/null bs=2g
 > dd: stdin: Bad address
 > 0+0 records in
 > 0+0 records out
 > 0 bytes transferred in 0.021 secs (0 bytes/sec)
 > $
 > 
 > does it still crash for you?
 
 I cant test on the original machine anymore (it has gone under
 production running Linux with only 48GB ram). So itried to reproduce
 it on a smaller and64 machine with only 8GB ram ...
 
 I can't make it crash, as i can't make any network trafic ;)
 
 njoly@lanfeust [~]> cat /dev/zero | rsh localhost dd of=/dev/null bs=2g
 dd: stdin: Bad address
 0+0 records in
 0+0 records out
 0 bytes transferred in 114.770 secs (0 bytes/sec)
 
 It doesn't return as fast as your test, the dd process cannot be
 killed during that time (even with kill -9), it eats memory and may
 make the system unresponsive.
 
 I then checked a few other bs values for the same command line. No
 problem with 1024m, 1536m, 2047m ... all other upper values fails. So
 there's still something weird with bs >= 2g when piping to rsh. Just
 for the record, every value i tested again worked just fine without
 rsh after pipe (= locally).
 
 But no crash.
 
 -- 
 Nicolas Joly
 
 Projects and Developments in Bioinformatics
 Institut Pasteur, Paris.