RNTuple `ReadBulk` after `AdoptBuffer` results in a segmentation violation

[rybkine]

Check duplicate issues.

• Checked for duplicates

Description

The expected behavior is to fill the provided buffer with data rather than a segmentation violation.

Reproducer

root -q ntpl001_staff_read_bulk_buffer_adopt.C+

ntpl001_staff_read_bulk_buffer_adopt.C.txt

issue_buffer_adopt_masked.log

ROOT version

---

| Welcome to ROOT 6.39.01 https://root.cern |
| (c) 1995-2025, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Apr 12 2026, 22:54:50 |
| From heads/master@v6-39-01-1857-gd0566ab4a9c |
| With g++ (GCC) 15.2.0 std202302 |
| Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q' |

Installation method

sft nightlies at cern

Operating system

Red Hat Enterprise Linux release 9.7 (Plow)

Additional context

Related to ATLAS Core Software ticket ATEAM-1127

[silverweed]

Hello @rybkine,
the buffer given to AdoptBuffer must contain initialized data, which is not the case if you just create it as malloc(size * sizeof(std::string)).
For non-trivial types you would need to in-place construct the elements, e.g. like

      // ...
      } else if (field->GetFieldName() == "Division" &&
                 (buffer = std::malloc(size * sizeof(std::string)))) {
        for (auto i = 0u; i < size; ++i)
          new (&static_cast<std::string*>(buffer)[i]) std::string();
        bulk.AdoptBuffer(buffer, size);
        // ...

and remember to destruct them before freeing the pointer.

However this approach is a bit questionable: AdoptBuffer is probably not going to give you much if you're going to read strings or other types that manage their own memory, as you'll only save one allocation but not the other size ones (one per string), at the expense of safety.

I understand this is just an example, but why do you need AdoptBuffer in the general case?

[rybkine]

We would like to use AdoptBuffer in order to optimize bulk reading (per field) which is much slower than reading per event. Providing a buffer would be similar to providing an entry once (with RNTupleReader::CreateEntry()) and then using RNTupleReader::LoadEntry(index, entry ) when reading per event. The goal is to allocate a buffer for bulk reading no more than once per field (reading all the clusters with the same buffer). Given that, why to initialize the buffer which initially contains no data and on each read its contents get overwritten? It would also make performance worse.

[silverweed]

why to initialize the buffer which initially contains no data and on each read its contents get overwritten?

If the field could not assume that the buffer elements have been constructed already it would have to reconstruct the object every time a ReadBulk is issued; instead what it does e.g. in the case of strings is simply resizing the string and overwriting its data buffer (see here). For resize to work, the string needs to be in a valid state.

However let me understand your use case a little better: if you create a Bulk once per field and reuse it it will achieve the same as the Entry analogy you brought up even without adopting the buffer, no?