aboutsummaryrefslogtreecommitdiff
path: root/include/ctf-api.h
diff options
context:
space:
mode:
authorNick Alcock <nick.alcock@oracle.com>2024-06-11 19:37:54 +0100
committerNick Alcock <nick.alcock@oracle.com>2024-06-18 13:20:31 +0100
commit1cdcc977329d8729745ad5f1389a39b9dc423754 (patch)
tree231fb8b36aa2fb9e8254bb270fb7ab859fb05f9b /include/ctf-api.h
parent28c812b34906c058a599924cc6ef399726c22cb9 (diff)
downloadgdb-1cdcc977329d8729745ad5f1389a39b9dc423754.zip
gdb-1cdcc977329d8729745ad5f1389a39b9dc423754.tar.gz
gdb-1cdcc977329d8729745ad5f1389a39b9dc423754.tar.bz2
libctf: strtab corruption when strings are added to ctf_open()ed dicts
ctf_str_add_ref and ctf_str_add_movable_ref take a string and are supposed to return a strtab offset. These offsets are "provisional": the ref mechanism records the address of the location in which the ref is stored and modifies it when the strtab is finally written out. Provisional refs in new dicts start at 0 and go up via strlen() as new refs are added: this is fine, because the strtab is empty and none of these values will overlap any existing string offsets (since there are none). Unfortunately, when a dict is ctf_open()ed, we fail to set the initial provisional strtab offset to a higher value than any existing string offset: it starts at zero again! It's a shame that we already *have* strings at those offsets... This is all fixed up once the string is reserialized, but if you look up newly-added strings before serialization, you get corrupted partial string results from the existing ctf_open()ed dict. Observed (and thus regtested) by an upcoming test (in this patch series). Exposed by the recently-introduced series that permits modification of ctf_open()ed dicts, which has not been released anywhere. Before that, any attempt to do such things would fail with ECTF_RDONLY. libctf/ * ctf-string.c (ctf_str_create_atoms): Initialize ctf_str_prov_offset.
Diffstat (limited to 'include/ctf-api.h')
0 files changed, 0 insertions, 0 deletions