The method (*XlaComputation).SerializedHLO in xlabuilder/xlacomputation.go ends like this:

	var vectorData *C.VectorData
	vectorData = (*C.VectorData)(C.XlaComputationSerializedHLO(unsafe.Pointer(comp.cXlaComputation)))
	return cbuffer.New(unsafe.Pointer(vectorData.data), int(vectorData.count), true)

The C function XlaComputationSerializedHLO does this:

  return str_to_bytes(module_str);

The function str_to_bytes looks like this:

VectorData *str_to_bytes(const std::string &s) {
  VectorData *v = Malloc<VectorData>();
  v->count = s.size();
  void *data = malloc(v->count);
  memcpy(data, s.data(), v->count);
  v->data = data;
  return v;
}

The important point is that uses malloc to allocate a value of type VectorData. Then it uses malloc to allocate the contents of the vector. There are two memory allocations here.

Looking back at the Go code in (*XlaComputation).SerializedHLO, we see that the contents of the vector are passed to cbuffer.New, which takes ownership of the memory allocation. However, the other memory allocation, of the VectorData value, is referenced and then dropped. It is never freed.

The Go code should look something like this:

	cbuf := cbuffer.New(unsafe.Pointer(vectorData.data), int(vectorData.count), true)
	C.free(unsafe.Pointer(vectorData))
	return cbuf

I'm not creating a pull request because I don't want to go to the trouble of installing everything I need to properly this. I hope it's clear that there is a memory leak here that needs to be address. Happy to answer any questions.