Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jun 1997 19:20:24 PDT
From:      Bill Fenner <fenner@parc.xerox.com>
To:        FreeBSD-gnats-submit@FreeBSD.ORG
Subject:   bin/3942: mmap fails on large file on CDROM
Message-ID:  <199706240220.CAA15275@sundae.parc.xerox.com>
Resent-Message-ID: <199706240230.TAA15321@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         3942
>Category:       bin
>Synopsis:       mmap fails on large file on CDROM
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 23 19:30:03 PDT 1997
>Last-Modified:
>Originator:     Bill Fenner
>Organization:
Xerox
>Release:        FreeBSD 2.2-RELEASE i386
>Environment:

	
2.2-RELEASE.

>Description:

	
tail dies on a large file located on CDROM.  I think this is symptomatic
of mmap() not working properly on iso9660 filesystems.

If you're debugging this, you might want to edit forward.c and
remove the "register" from the declaration of 'size' in rlines()
so that you don't get confused by the fact that gdb didn't know
which registers gcc put 'size' into (gdb thought it was in %ebx
and %esp, when it was really in %ebx and %esi).  I spent a while
debugging why the value got smashed when it was just gdb printing
gibberish.

# gdb ./tail
run GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...
(gdb) run /cdrom/flapometer.out.Jun10-19
Starting program: /usr/src/usr.bin/tail/./tail /cdrom/flapometer.out.Jun10-19

Program received signal SIGSEGV, Segmentation fault.
0x1a8d in rlines (fp=0x80860e0, off=10, sbp=0xefbfdc70) at forward.c:220
220                     if (*--p == '\n' && !--off) {
(gdb) p p - start
$2 = 156628054
(gdb) p *(start+156626944)
$1 = 0 '\000'
(gdb) p *(start+156626943)
$2 = 101 'e'
(gdb) p *p
$3 = 0 '\000'

By the time I got to do any debugging, it's mapped in a page of
zeroes, but I'm pretty sure that *p was on an unmapped page and
that's why it got a SEGV.  Note that *(start+156626943) (the end
of the previous page) is the last bit of useful data; there are no
NUL's in this file.

-rw-r--r--  1 fenner  wheel  156628056 Jun 23 18:08 flapometer.out.Jun10-19

Once I've managed to do whatever the debugger did to get the page
of nul's mapped, it's sticky.  I can run tail, but the last page
(1112 bytes) is filled with NUL's instead of the data I expect:

# tail /cdrom/flapometer.out.Jun10-19 | cat -v
06/19/97 16:00:44 205.189.33.88/30 metric change 19 1391 flaps
06/19/97 16:00:44 205.189.33.140/30 metric change 20 87 flaps
06/19/97 16:00:44 205.189.33.152/30 metric change 19 1418 flaps
06/19/97 16:00:44 205.189.33.252/30 metric change 10 1768 flaps
06/19/97 16:00:44 129.46.91.233/32 metric change 21 5091 flaps
06/19/97 16:00:44 129.46.93.41/32 metric change 6 5148 flaps
06/19/97 16:00:52 129.46.14.0/23 metric change 6 6094 flaps
06/19/97 16:00:52 129.46.100.0/23 metric change 6 6169 flaps
06/19/97 16:00:52 129.46.104.0/23 metric change 6 6236 flaps
06/19/97 16:00:52 129.46.106.0/23 metric change^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

I have some vague suspicion that the two different failure modes are
due to the presence or absence of the file in the buffer cache, since
once I've experienced the second behavior it seems to be sticky, but if
I read a bunch of files to try to thrash the cache it sometimes goes
back to the first behavior.


Neither error occurs when tail'ing the same file when it resides on
a disk:

# ./tail /sundae/fenner/flapometer.out.Jun10-19
06/19/97 16:00:52 129.46.124.0/23 metric change 6 6050 flaps
06/19/97 16:00:52 129.46.126.0/23 metric change 6 6117 flaps
06/19/97 16:00:52 129.46.128.0/23 metric change 6 3988 flaps
06/19/97 16:00:52 129.46.130.0/23 metric change 6 3910 flaps
06/19/97 16:00:52 129.46.136.0/23 metric change 6 3720 flaps
06/19/97 16:00:52 129.46.144.0/23 metric change 6 4391 flaps
06/19/97 16:00:52 129.46.180.0/23 metric change 6 3488 flaps
06/19/97 16:00:52 129.46.184.0/23 metric change 6 3382 flaps
06/19/97 16:00:52 129.46.188.0/23 metric change 6 3311 flaps
06/19/97 16:00:52 129.46.190.0/23 metric change 6 3274 flaps


>How-To-Repeat:

	
mmap() a big file on a CDROM like tail does, notice that the last page
is sometimes not mapped and sometimes filled with zeroes.

>Fix:
	
	
unknown.
>Audit-Trail:
>Unformatted:



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