[
https://issues.apache.org/jira/browse/THRIFT-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-4873.
--------------------------------
Fix Version/s: 0.14.0
Assignee: Jens Geyer
Resolution: Duplicate
> Memory leak in c_glib
> ---------------------
>
> Key: THRIFT-4873
> URL: https://issues.apache.org/jira/browse/THRIFT-4873
> Project: Thrift
> Issue Type: Bug
> Components: C glib - Compiler
> Affects Versions: 0.11.0, 0.12.0, 0.13.0
> Reporter: Matej Kupljen
> Assignee: Jens Geyer
> Priority: Major
> Fix For: 0.14.0
>
>
> Using the following thrift definition, compiler generates code that is
> leaking memory:
> {code:java}
> enum Command {
>
> CMD_A = 0,
>
> CMD_B = 0,
>
> CMD_C = 0,
>
> }
>
>
>
> struct CommandRequest {
>
> 1: string id;
>
> 2: i32 type;
>
> 3: list<Command> commands;
>
> }
> {code}
> Since we use Enum element for the list, compiler uses GArray for that, like:
> {code}
> struct _CommandRequest
>
> {
>
> ThriftStruct parent;
>
>
>
> /* public */
>
> gchar * id;
>
> gboolean __isset_id;
>
> gint32 type;
>
> gboolean __isset_type;
>
> GArray * commands;
>
> gboolean __isset_commands;
>
> };
>
> typedef struct _CommandRequest CommandRequest;
> {code}
> However, when reading the object from stream, it allocates memory for every
> element that it reads:
> {code}
> for (i = 0; i < size; i++)
>
> {
>
> Command* _elem0 = g_new (Command, 1);
>
> gint32 ecast1;
>
> if ((ret = thrift_protocol_read_i32 (protocol, &ecast1, error))
> < 0)
> return -1;
>
> xfer += ret;
>
> *_elem0 = (Command)ecast1;
>
> g_array_append_vals (this_object->commands, _elem0, 1);
>
> }
> {code}
> Although when clearing this element with g_array_unref, this does not free
> memory.
> From Glib documentation we should set g_array_clear_func() if we want to
> free memory allocated for elements:
> {quote}If array contents point to dynamically-allocated memory, they should
> be freed separately if free_seg is TRUE and no clear_func function has been
> set for array .
> {quote}
> But I believe the best option would be just to read the elements into int and
> casting it to proper type, without allocating memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
