Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Dec 2001 22:58:10 +0100
From:      Thomas Zenker <thz@tuebingen.netsurf.de>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        hackers@freebsd.org
Subject:   Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
Message-ID:  <20011213225810.A5144@peotl.homeip.net>
In-Reply-To: <200112132140.fBDLek699925@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Dec 13, 2001 at 01:40:46PM -0800
References:  <59687.1008231593@winston.freebsd.org> <200112131058.fBDAwSR66790@apollo.backplane.com> <20011213221204.A2994@peotl.homeip.net> <200112132140.fBDLek699925@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 13, 2001 at 01:40:46PM -0800, Matthew Dillon wrote:
> 
> :Matt,
> :
> :what the hell, this seems to very near by a problem I wanted to
> :report since a week:
> :
> :in a data acquisition I have a write process writing to a file
> :backed shared mmapped ringbuffer. There can be several reader
> :processes on this this ringbuffer. Now once i killed the writer for
> :resizing of the ringbuffer and forgot about the readers. The writer
> :truncated the database without unlinking it before. This lead the
> :readers to be running for ever, it seemed so at least.  After
> :attaching with gdb I saw, that they were only page faulting nothing
> :more, for ever....
> :
> :Something similar I saw with netscape going mad.
> :
> :cheers, Thomas
> 
>     That's something else.  There's no OS bug there.   When you mmap()
>     a file only those pages that are within the file's boundries are
>     valid.  So if you ftruncate() the file then all the pages occuring
>     after the (new) file EOF will become invalid and BUSfault if the 
>     process touches them.
> 
>     You touched upon the correct solution... remove() the file instead
>     of ftruncate()ing it.  The file's data then remains intact for the
>     processes still referencing it.
> 
>     The readers must be catching SIGBUS and retrying (not exiting),
>     causing them to run in a signal loop forever.  This is a case of
>     bad programming.  I've seen it before... there was a popular IRC
>     bot back in my BEST days which constantly got itself into infinite
>     loops because the guy who wrote it installed a signal handler for
>     SIGBUS.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>


well, I know, that this was a bug in my software, not to unlink the
file first and then truncating :-). But SIGBUS was not catched in
the readers.  Will try to reproduce it.

Thomas


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011213225810.A5144>