Re: mmap and SIGBUS

[Pavel Roskin <proski gnu org>]

Hello!

> > Yep, seen that discussion. I did not agree with jamie, IMNSHO SIGBUS
> > sometimes is better than not being able to view files > virtual mem.

This statement is not clear.  As I understand, getting SIGBUS would kill
MC, which implies not being able to view files on which it happens.

> I like SIGBUS because it can be used for error detection and recovery.
> (When it is implemented correctly and returns the address in
> siginfo->si_addr; not all the Linux targets do this properly, in fact
> i386 was one that did not pass a test of this)

I believe that it's better if mmap just failed instead of returning
success and allocating memory that cannot be accessed.  Maybe there is a
flag that would cause mmap to fail?

> And I like mmap, not just because of the file size thing but because it
> should provide the fastest parsers and reduce VM page duplication.  (I
> use it for text parsing, and so does GCC these days).  SIGBUS is an
> essential ingredient in fast parsers, if they are to recover on
> problematic filesystems.  Fortunately, recovery from SIGBUS _is_
> possible when it's required.

I'm not very experienced in such matters, but I understand that the only
way to recover after SIGBUS and SIGSEGV is to use longjpm in the signal
handler.  Otherwise, the same instruction is executed, and if it's
something like "movl (%edx), %eax", there is no way to prevent it from
failing over and over again.  Is it correct?

> I disagree say that accepting the occasional program crash is ok though
> -- that sort of "unlikely" thinking reminds me too much of the recent
> painful realisation that I can't run simple Gnome apps over an
> SSH-tunnelled X session (bah!), so I can't access my remote GnomeCal
> calendar (double bah, whatever happened to lovely X network transparency?).

I agree with you that any crash is bad, unless it's meant to kill resource
hogs (SIGXCPU, SIGXFSZ).

I can intercept SIGBUS, but should the viewer refuse to view the file at
all or it should revert to loading the whole file in memory?

Your sentiment about network transparency is very understandable.  Some
people want their fancy keyboard combinations work they do in Windows, but
the terminfo database doesn't have entries for keys like Ctrl-Alt-PgUp.
Making everyone happy requires either hacks or redesigning very
fundamental things.

> What I wrote about dirtying all the pages is something you have to do if
> you want to be sure your program sees a snapshot of the file at "load"
> time, in the style of an editor that has a "Load File" operation.  To
> ensure it works with huge files, I suppose you could copy the edited
> file and mmap the copy, instead of touching any pages.
>
> For a file viewer such as GMC, perhaps that behaviour is not important.

Agreed.

> Trapping SIGBUS and recovering in a file viewer is important IMO, not
> least because it is quite easy to do.  You don't even need
> siginfo->si_addr if you know which file is being parsed for the display
> at SIGBUS time, and the parsing/display code itself does not need any
> special code.

The viewer is written in a highly reentrant manner, but it should be
possible to set some static variable to the "struct view" containing all
the inforamtion about the current viewer instance before doing "dangerous"
things, like accessing the mmap()ed memory the first time.

If SIGBUS can arrive during any memory access, not just the first one,
then it may be harder to do, but still possible (only the currently
displayed viewer is likely to be "guilty").

"info libc" (glibc-2.2.4) doesn't mention "siginfo" and "si_addr".  Is it
Linux-specific?

-- 
Regards,
Pavel Roskin