Grommet.XBee Memory Leak?

Oct 31, 2011 at 5:49 PM

I'm currently building a simple sensor mesh network using the Xbee and I'm seeing an odd effect when the Coordinator node is not active.

If the coordinator node is turned off, the SZARRAY and CLASS categories in the garbage collection report continue to rise until the runtime on the sender/sensor node throws an "Out of Memory" exception.

I'm using the SendString() method with a null callback since I don't care about transmision confirmation:

_grommetXBee.SendString(0, 0, message, null);

Any suggestions on workarounds or fixes?

Oct 31, 2011 at 7:34 PM

I never noticed this before.  Let me take a look.

Oct 31, 2011 at 10:34 PM


I'm using the FEZ Panda board and the v4.1 Micro Framework (FEZ doesn't support v4.2 yet).

From the debugging I did, it looks like if the Coordinator node is off, then the frameBuffer in XBeeModule fills up as the frames in the buffer are not removed.

I'm not sending a high message volume, 2 - 3 messages every 5 seconds, each message approx 32 bytes in length.

I have a workaround at the moment, which is to call DropCallback() after SendString() in order to clear the frame from the buffer explicitly.

This also meant that I had to add a line of code to the XBeeModule.ReceivedTransmitStatus method to check if the sentFrame is already null.

      ApiFrame sentFrame = frameBuffer[frameID];  

      if (sentFrame == null) return;  // Added this line

A bit of a hack, but it means that the sensor nodes keep transmitting even when the Coordinator is powered down and recover when the Coordinator node re-appears on the network. Without this, the sensor nodes would require rebooting if the Coordinator node ever failed for a period of time.

Nov 1, 2011 at 4:00 AM

I think you have half of the correct fix.  The change you made to XBeeModule.ReceiveTransmitStatus is definitely fixes a bug. Notice the missing symmetry with XBeeModule.ReceivedATCommandResponse. The other change that should be made is to XBeeModule.SendApiFrame. Change:

frameBuffer[frameID] = frame;


frameBuffer[frameID] = (frame.Callback != null) ? frame : null;

Since, the saving of the frame is for supporting callbacks.  I might also reduce the number of frames allowed to be outstanding from 256 to something a little more reasonable (well definitely make it a constant).

I'm in the middle of a move right now, but I'll make the change to the source as soon as I can.

Thanks for finding this!