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 > <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
