Robert, Ok, as per my previous email, I've been looking at a table which uses row-creation, and this is causing a couple of problems - although this could be related to my implementation because I'm a little unsure about a couple of things. Maybe you could help clarify things please.
First some debug for you to show the error that I'm getting (see the subcontainer remove error): internal:<table>:_mfd_<table>_set_values: called internal:<table>:_<table>_set_column: called for 2 verbose:<table>:ParameterRowStatus_set: called internal:<table>:_<table>_set_column: called for 3 verbose:<table>:ParameterKey_set: called internal:<table>:_<table>_set_column: called for 4 verbose:<table>:ParameterValue_set: called internal:<table>:_<table>_set_column: called for 5 verbose:<table>:ParameterId_set: called internal:<table>:_mfd_<table>_commit: called verbose:<table>:<table>_commit: called internal:<table>:_mfd_<table>_irreversible:commit: called error on subcontainer remove (-1) internal:<table>:_mfd_<table>_undo_cleanup: called verbose:<table>:<table>_undo_cleanup: called verbose:<table>:<table>_release_data: called internal:<table>:_mfd_<table>_post_request: called internal:<table>:<table>_release_rowreq_ctx: called verbose:<table>:<table>_post_request: called In the <table>iterator irreversible_commit "CONTAINER_REMOVE" call am I responsible for the container - "<table>_if_ctx.container" or is this an internal thing to Net-SNMP? Also, if I try to create a row which already exists (i.e. has a duplicate index) then the iterator finds that index is there already (iterates through until it comes to that index) - but then the code still seems to continue to try and add the row rather than return an error. Do I need to implement this check somewhere - or should the net-snmp code handle this and return the error? Cheers Graeme > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Graeme Wilson > Sent: 02 July 2007 11:13 > To: Robert Story > Cc: [email protected] > Subject: RE: Memory leak in agent code using mfd > > > RS> Ugh. The iterator style mfd code is the least tested aspect of > > RS> this code. > > Oh well, I guess someone has to be the guinea pig and do some > application testing at some point :) > > > RS> rowreq_ctx->rowreq_flags |= (MFD_ROW_DELETED | > MFD_ROW_CREATED); > > > > RS> I think that will work, but it may cause other side effects > > RS> (especially if your table supports row creation). Give > it a whirl > > RS> and let me know how it goes.. > > Yes, I've tried this and it seems to be working much better > now (no memory leak). > My current table I've implemented doesn't support row > creation - but I do have one in the future that will. I'll > keep you updated if there are any side effects. > > One other minor issue for this mfd code (which is easily > fixed after the code generation). In the <table>_interface.c > code there is a call to a function > "_<table>_container_shutdown" in function > "_<table>_shutdown_interface". Unfortunately no > container_shutdown function exists. For the minute I've just > commented out this call together with the function > declaration at the top of the file. > > Cheers > Graeme > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Robert Story > > Sent: 28 June 2007 18:34 > > To: Graeme Wilson > > Cc: [email protected] > > Subject: Re: Memory leak in agent code using mfd > > > > On Thu, 28 Jun 2007 16:46:09 +0100 Graeme wrote: > > GW> ==12187== by 0x8049EF0: <table>_loop_get_first > > GW> (<table>_data_access.c:213) > > GW> ==12187== by 0x804C222: _<table>_loop_get_first_wrapper > > GW> (<table>_interface.c:753) > > > > Ugh. The iterator style mfd code is the least tested aspect of this > > code. > > > > I've just run through it again, after many years, and I > think I see a > > problem, which may or may not be the issue. The issue is > that the rest > > of the MFD code isn't expecting rowreq contexts to be > ephemeral. So, > > what's needed is a way to tell the rest of the code to release the > > context when it's done with it. Using the existing code, it > may be as > > simple as adding the following line in the allocat_rowreq > function in > > <table>_interface.c: > > > > rowreq_ctx->rowreq_flags |= (MFD_ROW_DELETED | MFD_ROW_CREATED); > > > > I think that will work, but it may cause other side effects > > (especially if your table supports row creation). Give it a > whirl and > > let me know how it goes.. > > > > -------------------------------------------------------------- > > ----------- > > 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. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Net-snmp-coders mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > > > > > > -------------------------------------------------------------- > ----------- > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Net-snmp-coders mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > > ------------------------------------------------------------------------- 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. http://sourceforge.net/powerbar/db2/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
