Re: unregistering handlers

Hi,
 I'm answering to my own mail to signal something which is either a bug
or a feature :) 
Il giorno mar, 12/10/2010 alle 18.41 +0200, Leo Cacciari ha scritto:
> Hi,
>The freeing callback call netsnmp_unregister_handler on its argument
>and I have deinit_mymodule calling netsnmp_free_all_list_data
[...snip...]
>   Then I thought that may be unregistering the handlers was not enough,
> what about data leak? Thus I tried to have the freeing callback calling
> netsnmp_handler_registration_free too. That was a bad idea, as now the
> subagent crashes when trying to call netsnmp_handler_registration_free
> on the first handler complaining that it tried to call free on some
> invalid pointer. 
[...snip...] Well, I tried to debug a little and I discovered that my
own callback for freeing handler data was called during the call for
netsnmp_unregister_handler. This fact gave me some idea, so i used gdb
to breakpoint into my data freeing callback, and got a stack backtrack.
Here it is:
#0  poster_data_free (data=0x8050af8) at posterdata.c:167
#1  0x00149f87 in netsnmp_handler_free (handler=0x8050e28)
    at agent_handler.c:589
#2  0x00149f6d in netsnmp_handler_free (handler=0x8050ef0)
    at agent_handler.c:580
#3  0x0014a059 in netsnmp_handler_registration_free (reginfo=0x8050e70)
    at agent_handler.c:633
#4  0x001420fb in netsnmp_subtree_free (a=0x8050f28) at
agent_registry.c:226
#5  0x00143fdb in unregister_mib_context (name=0x8050eb8, len=12, 
    priority=127, range_subid=0, range_ubound=0, context=0x0)
    at agent_registry.c:1197
#6  0x0014b5a3 in netsnmp_unregister_handler (reginfo=0x8050e70)
    at agent_handler.c:274
#7  0x003cb773 in poster_registration_free_calback (tofree=0x8050e70)
    at postermib.c:39
#8  0x0037a991 in netsnmp_free_list_data (head=0x8050978) at
data_list.c:27
#9  netsnmp_free_all_list_data (head=0x8050978) at data_list.c:39
#10 0x003cb8f0 in poster_unload_modules () at postermib.c:29
#11 0x003cad5d in deinit_PosterAgent () at posteragent.c:36
#12 0x08048c72 in main 

It is clear that netsnmp_unregister_handler calls
netsnmp_handler_registration_free, thus it is not surprising that a
successive call to that functions brings a segfault:

Program received signal SIGSEGV, Segmentation fault.
0x00447e39 in free () from /lib/libc.so.6
(gdb) bt
#0  0x00447e39 in free () from /lib/libc.so.6
#1  0x00149f95 in netsnmp_handler_free (handler=0x5323c0)
    at agent_handler.c:591
#2  0x0014a059 in netsnmp_handler_registration_free (reginfo=0x8050e70)
    at agent_handler.c:633
#3  0x0037a991 in netsnmp_free_list_data (head=0x8050978) at
data_list.c:27
#4  netsnmp_free_all_list_data (head=0x8050978) at data_list.c:39
#5  0x003cb8f0 in poster_unload_modules () at postermib.c:29
#6  0x003cad5d in deinit_PosterAgent () at posteragent.c:36
#7  0x08048c72 in main (argc=3, argv=0xbffff664) at main.c:83

Calling netsnmp_handler_registration_free from
netsnmp_unregister_handler can be, as I stated, either a bug or a
feature, but in any case I think it should be advertised in the
documentation. Anyhow, this answer my own question: yes, unregistering
handlers is enough for avoiding memory leaks (at least those related to
surviving handler registration structures).

By the way, everything above refers to release 5.5.



-- 
Leo Cacciari
Aliae nationes servitutem pati possunt. Populi romani est propria
libertas


------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users