Memory leak managing ib_field_val_t #16

Closed
niq opened this Issue Dec 9, 2011 · 4 comments

Comments

Projects
None yet
3 participants
@niq
Contributor

niq commented Dec 9, 2011

The union u field in ib_field_val_t leaks when it is allocated. This is a per-connection leak in the webserver/proxy plugins.

==1888== at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
==1888== by 0xE62595C: bstr_alloc (bstr.c:33)
==1888== by 0xEA57CB0: ib_bytestr_create (bytestr.c:92)
==1888== by 0xEA57D32: ib_bytestr_alias_mem (bytestr.c:184)
==1888== by 0xEA5833D: ib_field_alias_mem_ex (field.c:309)
==1888== by 0xE842BCA: ib_data_add_bytestr_ex (data.c:145)
==1888== by 0xEC60460: ironbee_conn_init (ironbee.c:651)

This is complex to deal with ad-hoc when it arises. Ideally ib_field_val_t should have a record of whether the value needs freeing, and a destructor to deal with it.

@niq

This comment has been minimized.

Show comment
Hide comment
@niq

niq Dec 9, 2011

Contributor

ib_field_val_t itself also leaks per-request:

==1888== at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
==1888== by 0xEA5661F: ib_mpool_alloc (mpool.c:223)
==1888== by 0xEA58315: ib_field_alias_mem_ex (field.c:304)
==1888== by 0xF66DF7A: modhtp_iface_gen_request_header_fields (htp.c:1120)

Contributor

niq commented Dec 9, 2011

ib_field_val_t itself also leaks per-request:

==1888== at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
==1888== by 0xEA5661F: ib_mpool_alloc (mpool.c:223)
==1888== by 0xEA58315: ib_field_alias_mem_ex (field.c:304)
==1888== by 0xF66DF7A: modhtp_iface_gen_request_header_fields (htp.c:1120)

@niq

This comment has been minimized.

Show comment
Hide comment
@niq

niq Dec 9, 2011

Contributor

and when a field is created/copied:

==1888== at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
==1888== by 0xE62595C: bstr_alloc (bstr.c:33)
==1888== by 0xEA57CB0: ib_bytestr_create (bytestr.c:92)
==1888== by 0xEA57F0E: ib_bytestr_dup (bytestr.c:121)
==1888== by 0xEA587E0: ib_field_create_ex (field.c:95)
==1888== by 0xEA58A62: ib_field_copy_ex (field.c:256)
==1888== by 0xE84271B: ib_data_tfn_get_ex (data.c:269)
==1888== by 0xFEEC290: lj_vm_ffi_call (in /usr/local/ironbee/lib/ibmod_lua.so

Contributor

niq commented Dec 9, 2011

and when a field is created/copied:

==1888== at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
==1888== by 0xE62595C: bstr_alloc (bstr.c:33)
==1888== by 0xEA57CB0: ib_bytestr_create (bytestr.c:92)
==1888== by 0xEA57F0E: ib_bytestr_dup (bytestr.c:121)
==1888== by 0xEA587E0: ib_field_create_ex (field.c:95)
==1888== by 0xEA58A62: ib_field_copy_ex (field.c:256)
==1888== by 0xE84271B: ib_data_tfn_get_ex (data.c:269)
==1888== by 0xFEEC290: lj_vm_ffi_call (in /usr/local/ironbee/lib/ibmod_lua.so

@b1v1r

This comment has been minimized.

Show comment
Hide comment
@b1v1r

b1v1r Dec 15, 2011

Contributor

Looks like the memory pool is not correctly registering the bstr cleanup functions as it is only tracking ONE function instead of list of them. Apparently this is a TODO item in the mpool code :) I'll fix that and that will hopefully solve many of these issues.

Contributor

b1v1r commented Dec 15, 2011

Looks like the memory pool is not correctly registering the bstr cleanup functions as it is only tracking ONE function instead of list of them. Apparently this is a TODO item in the mpool code :) I'll fix that and that will hopefully solve many of these issues.

@ghost ghost assigned b1v1r Dec 15, 2011

@ironbee

This comment has been minimized.

Show comment
Hide comment
@ironbee

ironbee Feb 15, 2012

Owner

With major recent changes to mpool code all mem leaks will be investigated as a task.

Owner

ironbee commented Feb 15, 2012

With major recent changes to mpool code all mem leaks will be investigated as a task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment