I believe this issue can be closed. It was apparently fixed as part of THRIFT-1583, "c_glib leaks memory" (in this commit). t_c_glib_generator::generate_deserialize_struct was modified so the generated code no longer creates a new object (a Column, in this case) but rather invokes thrift_struct_read on the one already created by the containing object's constructor.
Here's the relevant portion of the code generated for column_or_super_column_read by the compiler today:
if (ftype == T_STRUCT)
if ((ret = thrift_struct_read (THRIFT_STRUCT (this_object->column), protocol, error)) < 0)
No superfluous call to g_object_new and hence no memory leak.
I'll respond to Andris' comment above as it may be relevant to future contributors:
The change proposed by Jerry addresses the memory leak in this case, but does so by modifying the containing object's constructor so it does not initialize its member Column object during construction. This violates a principle observed throughout the rest of the C implementation, which is that serializable objects are initialized as early as possible.
This is done (I believe) because Thrift itself has no notion of a null object. If, for instance, a service method is defined as returning a map but for a particular invocation the method has no data to return, what the client receives is an empty map, not a null pointer or similar. As a result there is no reason for a serializable object or its members to ever not be initialized, as there is no way of representing them within the Thrift protocol otherwise. (This is my understanding, at least—perhaps someone more knowledgeable will correct me.)
So with Jerry's fix applied, newly constructed ColumnOrSuperColumn objects cannot be serialized at all. The correct fix was to stop the generated code from blindly re-initializing serializable objects' members; the compiler should know they are always initialized at construction.