Details
Major Description
Item 1:
*******
In the Avro-C implementation, there is a bug in the Raw x86 assembly
performing the atomic increment and decrement operations in
refcount.h. Specifically, the assembly language commands (mistakenly)
operate on the the pointer (refcount) instead of operating on the
memory pointed to (*refcount). This results in memory leaks, when
trying to deallocate avro values.
This problem only occurs when using GCC versions less than 4.1.0. For
GCC versions greater than 4.1.0, the code uses the GCC intrinsic
__sync_add_and_fetch() or __sync_sub_and_fetch() instead of the raw
x86 assembly, and this works properly.
Since this problem is masked for developers working with new(er) GCC
compilers, greater than version 4.1.0, one way to "uncover" it is to
force the GCC intrinsics off by requiring a higher GCC version (say
8.1.0) to use the GCC intrinsics. Then GCC falls back to using the x86
assembly, and the problem can be seen.
I am attaching a sample test case (test_refcount.c), which will show a
memory leak when compiled with the raw x86 commands enabled in
refcount.h and run with valgrind using the following command:
valgrind -v --leak-check=full --track-origins=yes ./test_refcount
I am also attaching a simple patch to fix the bug. The patch just
replaces (refcount) with (*refcount) in a few places, and the memory
leak disappears.
Item 2:
*******
On a related note, while compiling Avro across several flavors of
Linux, we noticed that the GCC atomic intrinsics
__sync_add_and_fetch() and __sync_sub_and_fetch() were not implemented
for all versions of GCC greater than 4.1.0, causing compile errors.
Specifically, the following two versions of GCC don't appear to
support the GCC atomic intrinsics:
1. GCC 4.1.2 20080704 (Red Hat 4.1.2-48)
2. GCC 4.4.3 on Mandriva for an i586 target
In our local code we have updated the GCC version test in refcount.h
to require versions of GCC greater than 4.5.0, before including the
GCC intrinsics. We might want to do the same in the global Avro
repository. If appropriate, I can create a separate JIRA item for
this issue. Please let me know.
Cheers,
Vivek Nadkarni
