sharpsnmplib Work Item Rss Feed

Commented Issue: How Messenger closes Sockets? [4988]

lextm — Mon, 05 Oct 2009 02:01:27 GMT

I'm getting a random exception from a monitoring windows service built using #SNMP. Exception is not catchable from .NET Framework code (it's a memory corruption inside Microsoft Visual C Runtime, during memcopy function).
Looking at memory mini dumps I found no clues about what's going on. Because this kind of exceptions are related to unmanaged resources, and my code is a pure .NET Framework application, all seems related to Windows Sockets.
So I had a look at how and when Messenger class closes UDP sockets, but found none. Socket are instanced using an Helper class, but no explicit Close method is called on socket instances (Shutdown is not needed because using connectionless ones). I modified Messenger class a bit (you can find it attached).
I'm I missing something? Maybe this is not useful at all?
Just to let you know a bit more about what I'm doing, my windows service is running SNMP tabular queries against many different devices, using a timer for scheduling. Crashes happen after a random amount of time, from 12 hours to 3 days.
Comments: ** Comment from web user: lextm **

Thanks for getting back with this information. It's my pleasure to assist you on this issue.

Regards,

Commented Issue: How Messenger closes Sockets? [4988]

andreabertolotto — Sun, 04 Oct 2009 12:16:05 GMT

Thank you so much for having a look at this and patching it.
This one just to let you know, memory leaks continued in my application even with new version of #SNMP. After about 10 days of tracing and WinDbg, I traced back a problem with .NET Framework class for Ping (it's in System.Net.NetworkingInformation). Before sending SNMP queries to my devices, I'm pinging them, to have a feedback on device availability. In a very concurrent environment, with low memory and strong processor pressure, GC introduces an unmanaged memory leak. This is reported in: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=157891.
So, again, thank you very much for all your efforts in this rock solid library.

Closed Issue: Small bug in TestGetTable example [5020]

lextm — Fri, 02 Oct 2009 10:10:01 GMT

Hello Lex,

I found a very small problem in for loops in TestGetTable example source code: all for loops (they are four) are evaluated to be less than table GetUpperBound, but that method is zero based, so evaluation should be less than or equal.

I.e. in code we have:

for (int row = 0; row < table.GetUpperBound(0); row++)

and it should be

for (int row = 0; row <= table.GetUpperBound(0); row++)

In actual code, tables with only one row are not shown at all.
Comments:

Fix checked in.

Commented Issue: Small bug in TestGetTable example [5020]

lextm — Fri, 02 Oct 2009 10:06:02 GMT

Thanks for the report.

I will check in the fix soon.

Created Issue: Small bug in TestGetTable example [5020]

andreabertolotto — Fri, 02 Oct 2009 06:02:04 GMT

Closed Issue: How Messenger closes Sockets? [4988]

lextm — Sat, 26 Sep 2009 02:26:43 GMT

This is a unmanaged resource leak. Was introduced when I started to roll back changes about sharing socket object.

Thanks for the report. I just checked in the fix to the repository.

Created Issue: How Messenger closes Sockets? [4988]

andreabertolotto — Fri, 25 Sep 2009 07:18:55 GMT

Created Issue: Loading an empty mib generates out of memory exception [4978]

lextm — Thu, 24 Sep 2009 08:31:31 GMT

I downloaded SNMPv2-CONF.mib along with a list of base mibs to load in my application. The content of SNMPv2-CONF.mib looks as shown below. When loading this mib, the application's memory usage continues to grow until out of memory exception is thrown. If i exclude this file, all the other mibs loads properly. So it looks like DefaultObjectRegistry has problem loading mibs that don't define any new object.

-- *****************************************************************

-- SNMPv2-CONF.my: SNMPv2 Conformance MIB file---- May 1994, Jeffrey T. Johnson---- Copyright (c) 1994,1996 by cisco Systems, Inc.-- All rights reserved.-- -- *****************************************************************---- This mib was extracted from RFC 1904-- All macro definitions have been removed because they are-- predefined in the mib compilerSNMPv2-CONF DEFINITIONS ::= BEGIN-- everything is predefined in the mib compilerEND

Closed Issue: WSACancelBlockingCall on receiving Inform messages

lextm — Fri, 31 Jul 2009 11:10:13 GMT

Often get this exception on receiving multiple inform messages:

A blocking operation was interrupted by a call to WSACancelBlockingCall
System.Net.Sockets.Socket.SendTo(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint remoteEP)
System.Net.Sockets.Socket.SendTo(Byte[] buffer, EndPoint remoteEP)
Lextm.SharpSnmpLib.Messaging.GetResponseMessage.Send(EndPoint receiver, Socket socket) at SharpSnmpLib\Messaging\GetResponseMessage.cs:line 121
Lextm.SharpSnmpLib.Messaging.InformRequestMessage.SendResponse(IPEndPoint receiver) at SharpSnmpLib\Messaging\InformRequestMessage.cs:line 107
Lextm.SharpSnmpLib.Messaging.DefaultListenerAdapter.Process(ISnmpMessage message, IPEndPoint sender) at SharpSnmpLib\Messaging\DefaultListenerAdapter.cs:line 97
Lextm.SharpSnmpLib.Messaging.Listener.HandleMessage(MessageParams param) at SharpSnmpLib\Messaging\Listener.cs:line 408
Lextm.SharpSnmpLib.Messaging.Listener.HandleMessage(Object o) at SharpSnmpLib\Messaging\Listener.cs:line 398
System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
Comments:

Commented Issue: WSACancelBlockingCall on receiving Inform messages

lextm — Fri, 31 Jul 2009 11:09:42 GMT

Now Socket.BeginSendTo is used. Not sure if this resolves the exception, as there is very limited information about such an exception available.

Patch checked in. Will be included in 3.0 beta 2.

Closed Issue: InformRequestMessage.Parameters always null

lextm — Fri, 31 Jul 2009 11:07:43 GMT

In current implementation it looks like :
public SecurityParameters Parameters { get { return null; }

Suppose it should be
public SecurityParameters Parameters { get { return _parameters; }
Comments:

Commented Issue: InformRequestMessage.Parameters always null

lextm — Fri, 31 Jul 2009 11:07:14 GMT

Also fixed TrapV2Message. Patch checked in. Will be included in 3.0 beta 2.

Created Issue: WSACancelBlockingCall on receiving Inform messages

sergei_m — Thu, 30 Jul 2009 04:53:19 GMT

Commented Issue: InformRequestMessage.Parameters always null

sergei_m — Wed, 29 Jul 2009 09:20:26 GMT

The same issue with
InformRequestMessage.Scope

Created Issue: InformRequestMessage.Parameters always null

sergei_m — Wed, 29 Jul 2009 09:19:04 GMT

In current implementation it looks like :
public SecurityParameters Parameters { get { return null; }

Suppose it should be
public SecurityParameters Parameters { get { return _parameters; }

Closed Issue: Querying multiple snmp enabled devices can fail

lextm — Sun, 19 Jul 2009 10:38:37 GMT

When querying several snmp-enabled devices, if querying one device causes failure (suggest as when it's off the network), then subsequent queries to other devices also fail. I've attached an example that demonstrates the problem.
Comments:

Commented Issue: Querying multiple snmp enabled devices can fail

lextm — Sun, 19 Jul 2009 10:38:20 GMT

Unit test cases added. After using sync version of Socket.Receive, we can continue using the old socket object. Please check TestTimeOut case of TestGetRequestMessage.

Commented Issue: Querying multiple snmp enabled devices can fail

ckitching — Mon, 15 Jun 2009 04:12:31 GMT

I'm experiencing this as well. The problem appears to be in ByteTool.GetResponse(IPEndPoint, byte[], int, int, Socket)

It calls Socket.BeginReceive(), but on timeout, it simply throws an exception without canceling the async request. Unfortunately, the only supported way to cancel a pending BeginRecieve() is to call Close(), which messes with the Messenger.GetSocket(AddressFamily) function that attempts to reuse sockets. This also means that Messenger is very thread unsafe.

If you need to work around this, I'd suggest just avoiding the SharpSnmpLib.Controls and using the base library directly. Unless you're walking the SNMP tree, it's pretty simple for gets and sets. Just remember that if you get a timeout, you must close the socket and recreate it.

Created Issue: Querying multiple snmp enabled devices can fail

chrisma — Wed, 03 Jun 2009 14:37:19 GMT

Closed Feature: add trap panel to Browser

lextm — Wed, 03 Jun 2009 11:41:55 GMT

This can make it easier to know what traps are captured.
Comments: