Re: Segmentation fault in dcigettext.c:925 using Apache + PHP

[Bruno Haible]

Wiebe Cazemier wrote:
> when [...] I generate a new mo file with msgfmt, two things can happen:
> 
> 1) it loses translations, even if I only remove one of the entries.
> 2) SIGBUS. This happens especially when the new .mo file is much shorter.
> 
> Apparently you can get SIGBUS when you're accessing outside of a mmap on a 
> file?

Yes, when a process has a file opened and mmaped, and you replace the
file (inode) with a smaller file contents (or call truncate() on it),
the process may get a SIGBUS and die from it.

> The original fault was a SIGSEGV, but the rest of the crash is similar.

When a process has a file opened and mmaped, and you replace the
file (inode) with a different contents, and the process interprets
some of the contents as indices - that's what dcigettext.c does -,
the process may get a SIGSEGV and die from it.

Now I understand that you are replacing the .mo file *while the application
(Apache + PHP) is running*.

This is likely to crash (with SIGBUS or SIGSEGV) if you do so in such a
way that the old .mo file and the new .mo file have the same inode.

It will not crash - and the process will continue to use the old .mo file -
if you do it in such a way that the inodes are different. So:

  cp new.mo $LOCALEDIR/$locale/LC_MESSAGES/domain.mo    => crash

  cp new.mo $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.new \
  && mv $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.new 
$LOCALEDIR/$locale/LC_MESSAGES/domain.mo
  => works

  ln $LOCALEDIR/$locale/LC_MESSAGES/domain.mo 
$LOCALEDIR/$locale/LC_MESSAGES/domain.mo.old \
  && cp new.mo $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.new \
  && ln -sf domain.mo.new $LOCALEDIR/$locale/LC_MESSAGES/domain.mo
  => works

It's like this for every file that is mapped. The kernel implements a write-
protection (cp would fail with ETXTBUSY) for some such files, namely swap files,
executables and shared libraries, but not for anything else.

Bruno