Codereview needed for #6929479

Martin Buchholz martinrb at
Sun Feb 28 02:04:53 UTC 2010

I think some documentation of the problem,
and a practical description of how users can
deal with it, is the most important thing.
Old unix-isms, like

cp test/foo.jar production/foo.jar
jar cf production/foo.jar ...
some...unix..command > production/foo.jar
rsync -a test/ production/

need to be exposed as avoidable (!) sources of SIGBUS.

I only recently learned about the following option
to rsync, which I have started using religiously
to try to reduce SIGBUS for my own customers:

              This option puts the temporary file from each updated file  into
              a holding directory until the end of the transfer, at which time
              all the files are renamed into place in rapid succession.   This
              attempts to make the updating of the files a little more atomic.
              By default the files are placed into a directory named "~tmp~"
              in  each file's destination directory, but if you've specified
              the --partial-dir option, that directory will be  used  instead.
              See  the  comments in the --partial-dir section for a discussion
              of how this ".~tmp~" dir will be excluded from the transfer, and
              what  you  can do if you want rsync to cleanup old "~tmp~" dirs
              that might  be  lying  around.   Conflicts  with  --inplace  and

Feel free to turn this email into educational material that
might reduce the SIGBUSes real users will encounter.


On Thu, Feb 25, 2010 at 11:09, Xueming Shen <Xueming.Shen at> wrote:
> This is a rfe to add a system property to enable the end
> user to disable the mmap usage in
> Sun's implementaiton (for Solaris and Linux
> platforms).
> Application uses might experience SIGBUS vm crash if
> the application mistakely over-writes
> zip/jar files that are still being used, for example the application server
> repeatedly deploy the same jar file into the
> same location again and again while there is still code (running in the same
> vm)  still accessing this particular zip/
> jar file (access the memory that mmapped the central directory of the zip
> file). While this is indeed an programming
> error in the offending application, there is situation that the end user
> really does not have the control of those
> applications and look for a workaround for the crash. With this property set
> to true (
> the sun zipfile implementation reads in the central directory into the
> memory instead of using mmap.
> Thanks,
> Sherman

More information about the core-libs-dev mailing list