memory leak using omapi?

[sscdvp at gmail.com]

Hi,
While looking through the file message.c,
I found that in function omapi_message_destroy()
in the following block

--cut--
        m = (omapi_message_object_t *)h;
        if (m -> authenticator) {
                omapi_typed_data_dereference (&m -> authenticator, file,
line);
        }
        if (!m -> prev && omapi_registered_messages != m)
                omapi_message_unregister (h);
--cut--

omapi message_unregister() for h argument (m has the value of h!) is never
processed because it tests the same condition for exiting prematurally
(return ISC_R_INVALIDARG):

--cut--
isc_result_t omapi_message_unregister (omapi_object_t *mo)
{
        omapi_message_object_t *m;
        omapi_message_object_t *n;
        if (mo -> type != omapi_type_message)
                return ISC_R_INVALIDARG;
        m = (omapi_message_object_t *)mo;
        /* Not registered? */
        if (!m -> prev && omapi_registered_messages != m)
                return ISC_R_INVALIDARG;
--cut--
I suggest commenting the block in omapi_message_destroy()
like this (leaving omapi_message_unregister() to try it's own test):

--cut--
        //if (!m -> prev && omapi_registered_messages != m)
                omapi_message_unregister (h);
--cut--

Can you make this change, recompile & run a valgrind test again?

Regards,
Serghei Samsi


2011/1/19 Wilson Yang <wyang at neoninc.org>

>  Hi,
>
>
>
> Found a email thread related to memory leak using omapi. Not sure if this
> has been fixed or a work around is available.
>
> Could you please shed some light on this?
>
> Appreciate your help in advance.
>
>
>
> An issue record, [ISC-Bugs #22784] has been created to address this
> behavior.
>
>
>
> Here is valgrind output while using v3.1-ESV
>
> ==2849== 70 (12 direct, 58 indirect) bytes in 1 blocks are definitely lost
> in loss record 37 of 39
>
> ==2849==    at 0x4022FBA: malloc (vg_replace_malloc.c:236)
>
> ==2849==    by 0x804FABF: dmalloc (alloc.c:80)
>
> ==2849==    by 0x805066C: omapi_value_new (alloc.c:1025)
>
> ==2849==    by 0x8055D10: omapi_generic_set_value (generic.c:160)
>
> ==2849==    by 0x805881A: omapi_message_set_value (message.c:160)
>
> ==2849==    by 0x8056A35: omapi_set_value (support.c:356)
>
> ==2849==    by 0x804CFFF: omapi_protocol_signal_handler (protocol.c:653)
>
> ==2849==    by 0x8052C3D: omapi_connection_signal_handler
> (connection.c:1018)
>
> ==2849==    by 0x805566E: omapi_io_signal_handler (dispatch.c:614)
>
> ==2849==    by 0x8056976: omapi_signal (support.c:290)
>
> ==2849==    by 0x804EBA7: omapi_connection_reader_trace (buffer.c:261)
>
> ==2849==    by 0x804E75F: omapi_connection_reader (buffer.c:137)
>
>
>
> And valgrind output while using v4.1-ESV,
>
> ==5828== 70 (12 direct, 58 indirect) bytes in 2 blocks are definitely lost
> in loss record 39 of 39
>
> ==5828==    at 0x4022FBA: malloc (vg_replace_malloc.c:236)
>
> ==5828==    by 0x804F596: dmalloc (alloc.c:75)
>
> ==5828==    by 0x804F663: omapi_value_new (alloc.c:1021)
>
> ==5828==    by 0x805473D: omapi_generic_set_value (generic.c:157)
>
> ==5828==    by 0x805784A: omapi_message_set_value (message.c:162)
>
> ==5828==    by 0x804D2DA: omapi_protocol_signal_handler (protocol.c:649)
>
> ==5828==    by 0x8055866: omapi_signal (support.c:286)
>
> ==5828==    by 0x804EAC3: omapi_connection_reader_trace (buffer.c:265)
>
> ==5828==    by 0x80536D2: omapi_one_dispatch (dispatch.c:520)
>
> ==5828==    by 0x8053D53: omapi_wait_for_completion (dispatch.c:290)
>
> ==5828==    by 0x804AC39: dhcpctl_wait_for_completion (dhcpctl.c:141)
>
> ==5828==    by 0x8049B7B: main (in /home/user/list_dhclient)
>
>
>
>
>
> Wilson Yang
>
> 720-836-2444
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20110120/399d1348/attachment.html>