Skip to content

Memory leak managing ib_field_val_t #16

niq opened this Issue Dec 9, 2011 · 4 comments

3 participants

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 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 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/

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.

@b1v1r b1v1r was assigned Dec 15, 2011
ironbee commented Feb 15, 2012

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

@ironbee ironbee closed this Feb 15, 2012
@b1v1r b1v1r removed their assignment Jan 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.