]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commitdiff
libctf: strtab corruption when strings are added to ctf_open()ed dicts
authorNick Alcock <nick.alcock@oracle.com>
Tue, 11 Jun 2024 18:37:54 +0000 (19:37 +0100)
committerNick Alcock <nick.alcock@oracle.com>
Tue, 18 Jun 2024 12:20:31 +0000 (13:20 +0100)
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.

libctf/ctf-string.c

index 0c5bd58cdafd11436cb86c886533923a5064de4a..2d96e45617cb7bf75353e4b47a35f991e9aa0049 100644 (file)
@@ -195,6 +195,8 @@ ctf_str_create_atoms (ctf_dict_t *fp)
       atom->csa_offset = i;
     }
 
+  fp->ctf_str_prov_offset = fp->ctf_str[CTF_STRTAB_0].cts_len + 1;
+
   return 0;
 
  oom_str_add: