This is a discussion on Re: small memory leak in snmp_api.c (WAS: Re: example app gives - SNMP ; On tor, 2007-07-05 at 15:28 +0300, Juuso Alasuutari wrote: > On Sunday 24 June 2007 23:21:46 Magnus Fromreide wrote: > > On s=F6n, 2007-06-24 at 14:14 +0200, Thomas Anders wrote: > > > Juuso Alasuutari wrote: > > > > ...
On tor, 2007-07-05 at 15:28 +0300, Juuso Alasuutari wrote:
> On Sunday 24 June 2007 23:21:46 Magnus Fromreide wrote:
> > On s=F6n, 2007-06-24 at 14:14 +0200, Thomas Anders wrote:
> > > Juuso Alasuutari wrote:
> > > > The distribution is Debian unstable, libsnmp version is 5.3.1, and
> > > > Valgrind is 3.2.3. Is this kind of behavior normal from libsnmp, or=
> > > > the test program's code broken in some way?
> > >
> > > Would you mind building net-snmp 5.4.1.pre3 from source, compile the
> > > test program against it and re-run your test?
> > Using trunk, the memory leak is due to init_snmp_enums where we try to
> > add both the string "gauge" and the string "unsigned" to the same key in
> > an snmp_enum that is indexed on the ASN.1 type tag.
> > According to my valgrind that is the definite memory leak.
> > /MF
> This still happens with 5.4.1.rc1.
> I investigated this and noticed you're right (although it's the =
> strings "uinteger" and "unsigned" that are added to the same key in =
> init_snmp_enums, not "gauge" and "unsigned").
> Init_snmp_enums calls se_add_pair_to_slist, which in turn calls =
> se_add_pair_to_list. Se_add_pair_to_list rejects "unsigned" because key 6=
6 is =
> already used by "uinteger", and returns SE_ALREADY_THERE. However, there =
> no return value check whatsoever in init_snmp_enums, and so the string wi=
> There already exists a friendly reminder in init_snmp_enums that these tw=
> keys are the same, but why both are still used is beyond me. Since the st=
> never makes it to the list, wouldn't it be better just to completely remo=
> line 761 from snmp_api.c? It worked for me.
The "asntypes" slist is used from agent/mibgroup/utilities/override.c
and there the use is in to look up the integer value using the string as
key. This will still break since the slist misses one value but the
right solution is, as I see it to
1. Move the list to the module that uses it - there is no reason
for every odd subagent to initialize this list so it could be
argued that all the elements are wasted resources.
2. Change to a data structure that is capable of handling the
requirements that are put upon it.
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Net-snmp-coders mailing list