GraphicTracker fails with AccessViolationException

[DavidClarke1]

I am developing an application using the GraphicTracker to display moving icons.  I am using the Windows.Forms.Timer event to suspend the display updates for two seconds.  I have another couple subroutines that creates and removes GraphicTrackerSymbols to the tracker.  All this happens on the same thread as the Windows.Forms.Timer does excute on the main gui thread.  I have also verified this in debug.

Every so often the program will crash with an AccessViolationException while trying to set the GraphicTracker.SuspendUpdate property to FALSE; it ALWAYS fails on trying to set that property to "FALSE".  What I noticed was that if I do not remove any items from the GraphicTracker it does not fail.  When I am removing items here and there as needed at some point it will fail.  It may be 30 seconds or 2 minutes.  I use the exact same test data (geometry/symbols/coordinates) but it still fails at some "random" time.  The map no longer updates on the screen and the whole map is unusable.  I cannot seem to recover or continue on.  Catching the exception makes no difference as the map just will not work anymore.

Here is the timer code.  The timer itself is set to run every 2 seconds.

_gt.SuspendUpdate = False System.Threading.Thread.Sleep(300) _gt.SuspendUpdate = True

My thoughts are that there is some timing issue while using the "Remove" method on the GraphicTracker object that conflicts with the "SuspendUpdate" property.  I have tried setting the timer to be a longer or shorter interval and also changing the "Sleep" interval but nothing seems to help.

[DavidClarke1]

Yes, I have looked at that many times.  The GLID is always different and is valid as I get no errors while trying to access the GLID of a graphic.  The key value in the dictionary is always different as well.  I thought it must be a data related error but I cannot find a pattern.  Of course the GraphicTracker looks like a black box to me so who knows what is going on in there!

[DavidClarke1 · Accepted solution]

I just received this from ESRI support.

NIM079055 - AccessViolationException when IGraphicTracker::Add is used to add many GraphicTrackerSymbols based on a PictureMarkerSymbol.

[BillLanza]

Any progress on this? Workarounds? This is kicking my &%#.

[JasonPike]

Any progress on this? Workarounds? This is kicking my &%#.

There is a workaround provided at the end of this thread:
http://forums.arcgis.com/threads/72516-Memory-Leak-with-Graphic-Tracker?p=272099&viewfull=1#post2720...

[DavidClarke1]

You'll have to call ESRI support and see if they have made any progress but I haven't heard anything since.

I did come up with one untested idea.  It might work to set the "visible" property to FALSE instead of removing items from the tracker.  Of course this could mean the memory leak problem might arise faster.  At some point I will need to try this out because I cannot come up with anything else at this point.

If anyone else has an idea, I would be interested in hearing it.  Even if it sounds crazy!

[DavidClarke1]

Thanks Jason,

I found the graphics container to be far worse performance than the tracker.  Although something that crashes and doesn't work at all isn't really better.

[JasonPike]

Thanks Jason,

I found the graphics container to be far worse performance than the tracker.  Although something that crashes and doesn't work at all isn't really better.

I agree--it is just the only workaround I know of. Someone should file a premium support case with ESRI.

[BillLanza]

I have found that the work around of setting the graphicstracker visibility to false almost stopped all my crashes.  It seems I am getting the access violation exception (from the geometry.dll) occassionally when moving objects. 
Also, according to ESRI Support, this bug is in the "assigned" state and there is no estimate for fix.

[ScottMcNeil]

I believe I ran into this same crash issue when I experimented with Graphics Tracker last year.  Never resolved it because I found the overall performance for my application to be inadequate (even without removing any items). 

I ended up using BaseCustomLayer and partial redraws.  It was not too difficult overall, but was tricky to get it to work without redrawing all my objects (caused annoying flickering), so I had to put them into different layers to get them to draw independently.  Depending on how many objects you have this may be an option for you.  I currently use it with up to about 20 layers, each having between 5-10 objects with labels, each updating once per second, and have adequate performance for my application (CPU is kept fairly busy though).  I also check for updates in a timer routine to prevent too many redraws.

[DavidClarke1]

In 10.1 you have the "Runtime" and "Engine" (formerly ArcEngine Runtime).  The "Runtime" is a new separate product and requires a rewrite for any version 10.0 code you have.

We have some developers who made a very promising prototype with the "Runtime".  The graphics outperform anything I have seen from ESRI so far.  The demo I saw (developed in house) had hundreds of items moving around the screen with very low CPU usage and very low memory footprint (hundreds of kilobytes instead of megabytes).

I cannot say if there are "Easter eggs" waiting to be discovered here but we will do more testing no doubt.  Although it would require a rewrite of code, it may be worth your time to investigate.

So far I have been burned by DynamicDisplay and now the GraphicTracker...