aboutsummaryrefslogtreecommitdiffstats
path: root/lib/erl_docgen/doc/src/part.xml
diff options
context:
space:
mode:
authorPatrik Nyblom <[email protected]>2012-11-21 17:58:19 +0100
committerBjörn Gustavsson <[email protected]>2012-11-22 10:23:00 +0100
commitb628ebe21a7b449eea27ada811dfbb007afe6d0b (patch)
treef8df42bfc4bb2421d248c5c7eead32ae5c868a66 /lib/erl_docgen/doc/src/part.xml
parentb0acd41f90490d38156cf9c8615859def630596b (diff)
downloadotp-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/erl_docgen/doc/src/part.xml')
0 files changed, 0 insertions, 0 deletions