Hi Robert,
Thank you for your response.
We have already implemented this table using autogeneration method. But
while doing a continuous query, I got memory leak in inetCidrRouteTable and
that's the reason I am going through all over again, specially
*_container_load() and add_ipv6_route_entries() .
Yes, we have used mib2c compiler to generate the code and which I feel it's
same to MFD template.
Apart from "Which method would you like to use to gather data about
available rows?" option all other option we choosed is DEFAULT.
For this option alone we have choosed second one which nothing but as
follows.
2) container-cached : This access method uses a netsnmp_container
to keep track of the indexes (and data, usually) for each
row. This method is best for:
- External data (maintained by another process/the kernel)
- Access speed is important
- Sufficient memory exists to contain all indexes
yes I agreed, Each route has its own row in the table. so obviously we need
a rowreq_ctx for each.
You need to release both (at the appropriate time). here do you mean I need
to clear the container as well as release memory for rowreq_ctx ???
Inside *_container_load(), rowreq_ctx contains a pointer to a memory
location.
those function which is created as part of template, for them as you told
we have comments to refer.
But my concern is related to add_ipv6_route_entries() which we manually
implemented. where again we are using a *rowreq_ctx and for each entry we
are allocating memory and inserting to container (through a loop)using
CONTAINER_INSERT(). So here, after using container again coming back to
caller which is inetCidrRouteTable_container_load().
So it would be great if you can provide some pointer or any exsting
documents/notes to let me understand the concept of CONTAINER_INSERT and
CONTAINER_FREE and other CONTAINER_ related functionalities.
--
Soubhagya
On Tue, Nov 8, 2016 at 7:16 AM, Robert Story <rst...@freesnmp.com> wrote:
> [Replying only to coders list]
>
> On Mon, 7 Nov 2016 19:25:49 +0530 Soubhagya wrote:
> SP> I have some queries with respect to memory leak in inetCidrRouteTable
> while
> SP> continuous query to inetCidrRouteTable .
> SP> [...]
> SP> As part of my project, we have added a support for ipv6 route entry in
> SP> "add_ipv6_route_entries()" under inetCidrRouteTable_container_load().
>
> So based on the examples you gave, you are writing your own implementation
> and not using the net-snmp code. Did you use the MfD template to generate
> your code?
>
> SP> here my question is where and how to free the newly allocated memory .
> The
> SP> reason why I am asking in this forum is whether to call release
> request or
> SP> need to check how can i use CONTAINER_FREE for this.
>
> This depends on the options you passed to mib2c when running the MfD
> template.
>
> SP> For reference pasting end part of my code snipet for both
> SP> inetCidrRouteTable_container_load() and add_ipv6_route_entries()
> SP> respectively. As you can see, rowreq_ctx is passed to CONTAINER_INSERT
> and
> SP> i hope it's being freed properly. But Inside add_ipv6_route_entries(),
> we
> SP> are again allocating memory for "rowreq_ctx" and again passing it to
> SP> CONTAINER_INSERT in same way. So here which one i need to take care of
> ??
>
> Each route is its own row in the table, so obviously you need a rowreq_ctx
> for each. You need to release both (at the appropriate time).
>
> SP> Whether I need to free the container or need to release memory by
> calling
> SP> inetCidrRouteTable_release_rowreq_ctx().?
>
> Again, this depends on how the code was generated. Do you completely
> rebuild the cache every time *_container_load() is called, or do you keep
> it around and only add/change new/changed rows? Does your rowreq_ctx only
> contain basic types and/or arrays, or does it contain pointers to allocated
> memory?
>
> If you used the MfD template, there should be comments throughout the code
> to help you out.
>
> --
> Robert
>
--
*Regards*,
Soubhagya
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
