SNMP Memory Leaks

There appears to be some memory leaks in the snmp3r.lib library -
specifically seems to be in the snmp_read() function - perhaps the PDU and
its associated memory is not properly freed? Does anyone have any insight
into this problem?

Brown, Richard wrote:

Some VCs must be inheritted accross exec calls. Why did you
think VCs should not be inherited accross exec calls?



The process inheritance table from QNX 4 online docs tells me virtual
circuits are not inherited across an exec call.

http://www.qnx.com/developer/docs/qnx_4.25_docs/qnx4/sysarch/proc.html

That’s indeed a good reason to think that :slight_smile:

There is an (obvious ?) inconsistancy in the docs though.
Since inheriting fds is optional with exec, and since an
fd that represents a connection to a remote resource manager
would require a vc, and since the table says vcs are never
inherited on exec, there should be a question mark about the
whole discussion wrt to vcs…

We came across the same problem which was confirmed by QSSL. Not holding
out much hope for a quick fix (it appeared that all attention was on QNX6)
we worked around it by execing a new copy of the executable to re-coup the
lost memory. This lead us to find another problem: VCs, which are not
supposed to be inherited across exec calls are inherited. To work around
that problem we had to scan the proc table for all VCs attached to our
process and issue a qnx_vc_detach on these before the exec. I haven’t seen
any new patches or releases and I have not heard if these issues have been
resolved.

I also found the timeout returned from the snmp_select_info continually
decreases until it reaches 0. Once it hits 0 then all snmp requests timeout.
I had to ignore the timeout returned from snmp_select_info and pick my own
timeout. Have you noticed this?

“Brian Delsey” <bdelsey@mindspring.com> wrote in message
news:arc0mt$dki$1@inn.qnx.com

There appears to be some memory leaks in the snmp3r.lib library -
specifically seems to be in the snmp_read() function - perhaps the PDU and
its associated memory is not properly freed? Does anyone have any insight
into this problem?

Out of desperation I was also considering the brute force execlp() option
but I was hoping for a less fugly solution. However it appears as though my
options are limited at this point - I think I will follow your lead.

I have also experienced the odd behaviour with the timeout returned from
snmp_select_info - but till now have been more concerned with the memory
leak issue.

Thanks for your response. Appreciate your help.

Regards

“Brown, Richard” brownr_aecl_ca@127.0.0.1 wrote in message
news:ard95a$r4j$1@inn.qnx.com

We came across the same problem which was confirmed by QSSL. Not holding
out much hope for a quick fix (it appeared that all attention was on QNX6)
we worked around it by execing a new copy of the executable to re-coup the
lost memory. This lead us to find another problem: VCs, which are not
supposed to be inherited across exec calls are inherited. To work around
that problem we had to scan the proc table for all VCs attached to our
process and issue a qnx_vc_detach on these before the exec. I haven’t seen
any new patches or releases and I have not heard if these issues have been
resolved.

I also found the timeout returned from the snmp_select_info continually
decreases until it reaches 0. Once it hits 0 then all snmp requests
timeout.
I had to ignore the timeout returned from snmp_select_info and pick my own
timeout. Have you noticed this?

“Brian Delsey” <> bdelsey@mindspring.com> > wrote in message
news:arc0mt$dki$> 1@inn.qnx.com> …
There appears to be some memory leaks in the snmp3r.lib library -
specifically seems to be in the snmp_read() function - perhaps the PDU
and
its associated memory is not properly freed? Does anyone have any
insight
into this problem?
\

David Gibbs wrote:

Now the question nobody likes to answer and I hesitate in asking: Is there
any chance these issues will be addressed with a patch?


I can almost guarantee that Proc’s behaviour in this will not be
changed. This would be a fairly major change, and the issues with
the possible instabilities this could introduce, (e.g. breaking
fd inheritance perhaps) are such that we are not going to risk
this at this point in Proc’s life cycle.

I realize this has nothing to do with me (I’m not even
sure what one would do with snmp if it worked perfectly)
and I have no problem with leaving Proc alone, but what
about a fix for the memory leak in snmp ? Wouldn’t that
solve both Brians’ and Richards’ problem…

Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:

This lead us to find another problem: VCs, which are not
supposed to be inherited across exec calls are inherited. To work around
that problem we had to scan the proc table for all VCs attached to our
process and issue a qnx_vc_detach on these before the exec.

Some VCs must be inheritted accross exec calls. Why did you
think VCs should not be inherited accross exec calls?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Some VCs must be inheritted accross exec calls. Why did you
think VCs should not be inherited accross exec calls?

The process inheritance table from QNX 4 online docs tells me virtual
circuits are not inherited across an exec call.

http://www.qnx.com/developer/docs/qnx_4.25_docs/qnx4/sysarch/proc.html

Rennie Allen <rallen@csical.com> wrote:

Brown, Richard wrote:
Some VCs must be inheritted accross exec calls. Why did you
think VCs should not be inherited accross exec calls?



The process inheritance table from QNX 4 online docs tells me virtual
circuits are not inherited across an exec call.

http://www.qnx.com/developer/docs/qnx_4.25_docs/qnx4/sysarch/proc.html

That’s indeed a good reason to think that > :slight_smile:

Yup. Very good reason.

There is an (obvious ?) inconsistancy in the docs though.
Since inheriting fds is optional with exec, and since an
fd that represents a connection to a remote resource manager
would require a vc, and since the table says vcs are never
inherited on exec, there should be a question mark about the
whole discussion wrt to vcs…

Yup again. That was exactly why I said that some VCs must
be inheritted accross exec calls.

It would appear that documentation is wrong. Or, at least, incomplete.

I’ll have to do some more research & testing and see what actually
happens, and what should happen.

My apologies for this causing you problems.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

There is an (obvious ?) inconsistancy in the docs though.
Since inheriting fds is optional with exec, and since an
fd that represents a connection to a remote resource manager
would require a vc, and since the table says vcs are never
inherited on exec, there should be a question mark about the
whole discussion wrt to vcs…

Yup again. That was exactly why I said that some VCs must
be inheritted accross exec calls.

It would appear that documentation is wrong. Or, at least, incomplete.

Agreed.

I think VCs tied to FDs should follow the inheritance of the FD. All other
VCs should NOT be inherited.

The VCs inherited in our exec were not tied to FDs.

My apologies for this causing you problems.

More frustration than anything else … we traded an SNMP memory leak for an
exec VC leak. In the end we were able to work around both.

Now the question nobody likes to answer and I hesitate in asking: Is there
any chance these issues will be addressed with a patch?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:

There is an (obvious ?) inconsistancy in the docs though.
Since inheriting fds is optional with exec, and since an
fd that represents a connection to a remote resource manager
would require a vc, and since the table says vcs are never
inherited on exec, there should be a question mark about the
whole discussion wrt to vcs…

Yup again. That was exactly why I said that some VCs must
be inheritted accross exec calls.

It would appear that documentation is wrong. Or, at least, incomplete.


Agreed.

I think VCs tied to FDs should follow the inheritance of the FD. All other
VCs should NOT be inherited.

The VCs inherited in our exec were not tied to FDs.

Yup, tested this. It seems that all VCs are inheritted accross exec.

Now the question nobody likes to answer and I hesitate in asking: Is there
any chance these issues will be addressed with a patch?

I can almost guarantee that Proc’s behaviour in this will not be
changed. This would be a fairly major change, and the issues with
the possible instabilities this could introduce, (e.g. breaking
fd inheritance perhaps) are such that we are not going to risk
this at this point in Proc’s life cycle.

I will be issuing a PR against the docs, the system architecture
section in particular, to make it correctly describe the behaviour
here.

inheritance for VCs:

fork() - as needed for maintaining other inherited resources, e.g. open files
exec() - yes
spawn - as needed…

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

A fix would be nice… or at least access to the snmp_read() code so that we
can make the fix ourselves. I’m not really happy with the exec() option -
its like a big piece of duc tape - not that there is anything wrong with duc
tape!

And regarding the “what would one do with snmp” comment - I have pondered
this often. Unfortunately I am being forced to use it by a customer who has
chosen to implement snmp as the communications interface to its controller.
I’ll never figure this one out… complete missuse of a protocol in my
opinion - possibly out of laziness.

Cheers

“Rennie Allen” <rallen@csical.com> wrote in message
news:3DDA5868.7070807@csical.com

David Gibbs wrote:

Now the question nobody likes to answer and I hesitate in asking: Is
there
any chance these issues will be addressed with a patch?


I can almost guarantee that Proc’s behaviour in this will not be
changed. This would be a fairly major change, and the issues with
the possible instabilities this could introduce, (e.g. breaking
fd inheritance perhaps) are such that we are not going to risk
this at this point in Proc’s life cycle.

I realize this has nothing to do with me (I’m not even
sure what one would do with snmp if it worked perfectly)
and I have no problem with leaving Proc alone, but what
about a fix for the memory leak in snmp ? Wouldn’t that
solve both Brians’ and Richards’ problem…

Rennie Allen <rallen@csical.com> wrote:

David Gibbs wrote:

Now the question nobody likes to answer and I hesitate in asking: Is there
any chance these issues will be addressed with a patch?


I can almost guarantee that Proc’s behaviour in this will not be
changed. This would be a fairly major change, and the issues with
the possible instabilities this could introduce, (e.g. breaking
fd inheritance perhaps) are such that we are not going to risk
this at this point in Proc’s life cycle.

I realize this has nothing to do with me (I’m not even
sure what one would do with snmp if it worked perfectly)
and I have no problem with leaving Proc alone, but what
about a fix for the memory leak in snmp ? Wouldn’t that
solve both Brians’ and Richards’ problem…

I didn’t coment on that, cause I know just about nothing about
SNMP, the versions of TCP/IP involved, whether we just ported
the SNMP libraries (and they’re standard BSD code) or we custom
wrote them, or anything.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.