ukkiwisurfer

Hi KiwiBryn,

 

I too have try/catch blocks (normally) around critical code sections. I realised over the weekend that even though I have an application level try/catch block, as the UDP capture code is running in its own thread, I was missing the associated try/catch block from the relevant thread looping code. Since making this change I'm not getting buffer overflow messages any more. 

 

The UDP thread captures whatever is in the buffer and then adds it to an internal (memory) queue. Another thread writes these blocks to the SD card (think micro-service architecture) using a StreamWriter in order to add additional metadata around the payload body. A third thread(service) reads these files off the SD and publishes to AMQP.

 

My next set of challenges is around an Unhandled Exception message being thrown from within the framework code (not a .NET exception) and a memory leak.

 

I have no idea where the un-handled exception is being thrown from but it seems to be happening around the point that my memory leak forces memory levels to a critical level. So my first plan of attack is to find the memory leak. To do this I'm going to disable all but one service and see if I can identify which service is leaking. Any other suggestions on approach? 

 

I've introduced a Debug.GC(true) into the code where I persist the file data via AMQP, which has helped considerably and I print out the free memory for reference. However over a couple of hours I can see the memory level gradually dropping. But obviously Debug.GC() just sticking plaster over a much more fundamental issue.

As I've introduced extensive logging statements into the code that also muddies the waters with regards to memory allocations for strings.

 

It would be nice if the tooling around .NETMF development moved into the late 20th century and not require print statements to identify leaks and the like. In cases like this I miss my crash dumps and WinDbg (however arcane the commands are) it definitely takes the guess work out of where objects are being pinned in memory.

 

Just imagine how more productive we would be.... :-)

 

Thanks,

Jason.

Hi KiwiBryn,

Sure, I can shed some details on the project. I'm building out a data capture platform, initially as a PoC for within the home.

The data is captured via a UDP broadcast that is happening elsewhere on the network. These packets are then saved as files on the SD card.

A separate thread runs, looking for files in a specific subdirectory, to then load each, one at a time into memory, before using amqp lite to transmit the data to a gateway (rabbitMQ).

Due to the lack of real analysis tools for the net mf platform that the desktop versions of .net support I've also had to write a generalised logging framework. To work out what is happening.

I wonder how you approach the same w.r.t logging and tracing on a constrained device?

Thanks,
Jason.

Hi KiwiBryn,

 

I hadn't actually considered File.ReadAllBytes(). I'll give it a try. With regards to payload size its consistently about 556 bytes, so quite small but I get about 1 message every 5 seconds (thereabouts). 

 

It does sound very similar. The only difference is I'm publishing to a RabbitMQ instance running locally for further processing before being pushed into the cloud. I've followed your other posts with interest. :-)

 

Your insight with regards to VolumeInfo.FlushAll() will probably help mitigate the corruptions I sometimes see on the SD. ie. https://github.com/N...eter/issues/235. So thanks for this as well.

 

Thanks,

Jason.

I would add that this error message isn't being recorded through my logging system, and when it happens it takes the whole board down. Only a restart will recover it. No .NET exception is being raised either which makes me highly suspicious.

 

1. Has anyone encountered this type of error before?

2. Any suggestions as to how to capture more error information around what is actually happening? If its not raising a .NET exception, are their any type of crash dump files that get generated? 

 

Thanks,

Jason.

Hi,

 

Thanks for the feedback. It confirms what I thought. There are some really helpful people out there in the community as I've already encountered.

 

I was just surprised there was only one primary contributor from Secret Labs.

 

Thanks,

Jason.