I tried to compile the latest code of filebeat on my Raspbarry Pi 3 (Arch ARM Linux, armv7h). The compilation was successful, however during runtime it crashed as follows
After some googling I found out that the 64-bit atomic must be aligned to a 64-bit address on ARM. This is however not achieved in the current Prospector struct. I tried adding a uint32 padding value before this field and now it works like a charm.
I have never programmed anything in Go before and I don't know if there's something more elegant to come along this problem. However, this should definitively be addressed in the code.
Please open a new issue for this. I think there could be two solutions. Make the counter a uint32 instead of uint64, or move the counter to the first value declared in the struct. Could you try latter?
Makes me wonder how well alignment requirements are supported by the compiler. There is no such thing as a special atomic type in go. That is, one has to be careful about placement of atomic fields in structs and hope for allocator(stack) to be always aligned (This should be the case). While not required for all architectures, proper alignment can still be beneficial/required, e.g. to ensure the atomic variable accessed does not overlap cachelines.
Structs employing atomics should also ensure to fit into a multiple of 8bytes, so using them in arrays is safe.
I think 32bit x86 also requires an 8byte boundary alignment (at least for 64bit atomic ops).
This issue made me curious. Never done anything before using Go. You're right, the data type itself is not atomic, but the operation on it which also requires the alignment.
As long as this isn't solved upstream, switching to uint32 for the number of prospectors should be safe. I guess 4 billion prospectors is suffienct for the moment
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
