diff options
author | Patrik Nyblom <[email protected]> | 2012-11-21 17:58:19 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2012-11-22 10:23:00 +0100 |
commit | b628ebe21a7b449eea27ada811dfbb007afe6d0b (patch) | |
tree | f8df42bfc4bb2421d248c5c7eead32ae5c868a66 /lib/runtime_tools/vsn.mk | |
parent | b0acd41f90490d38156cf9c8615859def630596b (diff) | |
download | otp-b628ebe21a7b449eea27ada811dfbb007afe6d0b.tar.gz otp-b628ebe21a7b449eea27ada811dfbb007afe6d0b.tar.bz2 otp-b628ebe21a7b449eea27ada811dfbb007afe6d0b.zip |
Teach erts_bs_append not to dump core
When erts_bs_append() calls the garbage collector, it has set
the PB_ACTIVE_WRITER flag in the ProcBin for the binary object
is about to be appended to. Therefore, it is expected that the
garbage collector should neither move nor shrink the binary
object.
But if the garbage collector does a minor collection (thereby
clearing the PB_ACTIVE_WRITER flag in the ProcBin) and there is
still not enough heap space, there will be a second major
garbage collection. During the major collection (since the
the PB_ACTIVE_WRITER flag was cleared), the binary object may
be shrunk or moved (depending on sizes and how many other
writable binaries there are in the process).
Avoid the problem by clearing the PB_ACTIVE_WRITER flags in
a separate pass after the garbage collection(s).
Thanks to Denis Titoruk for helping us find this bug.
Diffstat (limited to 'lib/runtime_tools/vsn.mk')
0 files changed, 0 insertions, 0 deletions