[PATCH 01/11] libctf: strtab corruption when strings are added to ctf_open()ed dicts

[Nick Alcock <nick.alcock@oracle.com>]

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 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libctf/ctf-string.c b/libctf/ctf-string.c
index 0c5bd58cdaf..2d96e45617c 100644
--- a/libctf/ctf-string.c
+++ b/libctf/ctf-string.c
@@ -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:
-- 
2.45.1.275.g567cb0950c