aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
diff options
context:
space:
mode:
authorPeter Klausler <35819229+klausler@users.noreply.github.com>2023-11-30 12:34:42 -0800
committerGitHub <noreply@github.com>2023-11-30 12:34:42 -0800
commitbddf5d20105e24cf708ff8c6ff49aa65af4e89b0 (patch)
tree8331f5feb65b2d9e1465c3ebbd204ce83e2d9abc /lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
parent248446980317dccadd5ecdf7d2831942baaff4ab (diff)
downloadllvm-bddf5d20105e24cf708ff8c6ff49aa65af4e89b0.zip
llvm-bddf5d20105e24cf708ff8c6ff49aa65af4e89b0.tar.gz
llvm-bddf5d20105e24cf708ff8c6ff49aa65af4e89b0.tar.bz2
[flang][runtime] Fix BACKSPACE-WRITE on variable-length unformatted file (#72732)
A subtle bug in buffer management is being caused by a WRITE on an unformatted file with variable-length records after one or more BACKSPACEs and some READs. An attempt at a minor optimization in BACKSPACE kept the footer of the previous record in the unit's buffer, in case more BACKSPACEs were to follow. If a later WRITE takes place instead, the buffer's frame would still cover that footer, but its content would be lost when the buffer became dirty on its first modification, and the footer in the file would be overwritten with stale buffer contents. As WriteFrame() implies the intent to define all the bytes in the identified range, the trick being used in BACKSPACE with its adjustment to frameOffsetInFile_ breaks any later WRITE... and so we just can't do it. Fixes https://github.com/llvm/llvm-project/issues/72599.
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp')
0 files changed, 0 insertions, 0 deletions