Again: innd got SIGBUS (fwd)
rra at stanford.edu
Wed Dec 20 01:38:09 UTC 2000
Mirek Luc <mirecki at nask.pl> writes:
> Right. But I shrank the active file by hand. In ICDiovset():
> where: base == ICDactpointer (mmap returned it),
> iovp->iov_len == ICDactsize (initial size of mmap'ed active)
> So memcpy tried to copy data from non-existent area (near the and of the
> "old" active file, before editing by hand). And this caused SIGBUS. In my
> opinion of course.
Ick. You really want to avoid editing the active file by hand if you can
avoid it. (One of the nice advantages to running nnrpd separate from innd
is that you can just do a ctlinnd shutdown for things like this and
readers won't even notice.)
But I agree with other posts that INN should really handle this better.
>> I'm not sure if the problem is OS issue.
> I don't know how mmap works in other OSes but Solaris' mmap(2) says:
> The mmap() function allows [pa, pa + len) to extend beyond
> the end of the object both at the time of the mmap() and
> while the mapping persists, such as when the file is created
> prior to the mmap() call and has no contents, or when the
> file is truncated. Any reference to addresses beyond the end
> of the object, however, will result in the delivery of a
> SIGBUS or SIGSEGV signal. The mmap() function cannot be used
> to implicitly extend the length of files.
> ICDiovset() (memcpy) tried "Any reference to addresses beyond the end of
> the object". That was in my case I think.
This is standard in pretty much every Unix-like.
>> Anyone runs innd on Solaris8 successfully?
> innd works fine for me.:-) Except throttle / edit active / go.
Try ctlinnd reload active in the middle there. What INN *should* do is
close the file and remap it, which should do the right thing. msync
really shouldn't be causing a SIGBUS even if you've truncated the file out
from under INN's nose, if I understand the virtual memory system
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers