Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

ukkiwisurfer

Member Since 22 Jan 2015
Offline Last Active Jan 27 2016 11:18 AM
-----

Posts I've Made

In Topic: Buffer OVFLW not being caught by try/catch

16 November 2015 - 10:02 AM

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.


In Topic: Buffer OVFLW not being caught by try/catch

15 November 2015 - 10:31 AM

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.

In Topic: ND3 SD Filestream.Read() seems to become broken

14 November 2015 - 11:29 PM

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.


In Topic: Buffer OVFLW not being caught by try/catch

12 November 2015 - 10:39 PM

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.


In Topic: General support from Secret labs

12 November 2015 - 01:07 PM

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.


home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.