Flatbuffers in Go and C++

Hi all, I am having issues with flatbuffers that are written in Go and segfaulting in C++. In Go, I can read C++ written flatbuffers file. But for in C++, it segfaluts trying to read a Go-written flatbuffers file.

I have 2 questions: 1. Has anyone tried doing this before and succeeded? C++ generated flatbuffers code is a lot more than the Go equivalent. 2. I'd be happy to share the fbs file and the code if it helps but didn't want to spam the forum.

Thanks!

it means, dump fbs binary with C++ and Go. but C++ can't read Go's generated binary?
I don't know C++implementation, but I have Go's project that using flatbuffer for libclang, and dump data into leveldb.
https://github.com/zchee/clang-server

So I might be able to help you.

Knowing very little about Flatbuffers (but being familiar with Cap'n Proto and Protocol Buffers), I would think that the same data serialized in C++ and Go should be bit-for-bit identical.

That would make me think that the issue is that the data isn't being read from file correctly, perhaps being parsed as text instead of binary. Sharing the data/code might help here.

I thought the same thing, but the Flatbuffers specification actually allows the serializer to control the ordering of fields to allow for {back,for}wards compatibility. So, technically, you can't rely on doing a byte-for-byte diff to compare a flatbuffer payload on-the-wire, since the ordering of member fields is not defined. My lack of better ideas is why I didn't post earlier.

Hi all, I figured out my issue finally. I was pushing the offsets to a slice declared as

var treeOffsets, nodeOffsets []flatbuffers.UOffsetT

And for some reason appending to these didn't take, and I had to change to
treeOffsets := make([]flatbuffers.UOffsetT, 0)
nodeOffsets := make([]flatbuffers.UOffsetT, 0)

And this fixed it. I thought append will allocate a new slice if there's no room, but I may have misunderstood how it works.
The final output is still not exactly the same for the 2 languages, but as /u/therealfakemoot said, the two may not be byte-to-byte the same anyway. 

Please keep in mind, that you still have the segfault in the C++ code. I strongly suggest fixing it, if it is anywhere near production use. In the best case, one could send broken data to perform a denial of service attack.