: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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
