CanvasClear causes the application to crash

[ulaf]

I'm using a simple rectangular canvas-control with moving indicator(Vshape) which displays currently measured value.

The value is updated 10 - 14 times per second, and deliberately, I made these values fluctuate.

The canvas is filled with gradient colors (5 ranges) and the indicator moves up or down. In order to redraw the indicator,

I'm using CanvasClear with VAL_ENTIRE_OBJECT attribute and thereafter redraws its content.  Few days ago I noticed,

that the software crashed, when the panel, containing the canvas control, was behind another window (belonging to another SW,

say msword, or programmers notepad). I have been able to reproduce the crash, which does not occur immediately but

after the software has been running anywhere from 0.5 to 5 hours and the questionable control has been behind another window.

I also have been able to observe, before the crash, if  I move the covering window away from the canvas-control, covered rectangle

becomes black (in non-crashing mode, it remains white) and it takes several seconds to redraw the partial region.

Sometimes I have noticed irregular elements (a diagonal line, not intended, running from top left corner to bottom right).

Labwindows2010 IDE always indicates crash-point as a call to CanvasClear().

None of the functions, manipulating the canvas-control, return negative values, as the software does check for it and if found logs an

appropriate message. The canvas control has Draw Policy as mark for update.

Does anyone have any idea how to go around such an instability or how do fix it?

I also have been able to capture disassembly and call-stack:

Unhandled exception at 0x6850226E (cvirte.dll) in sw_dbg.exe: 0xC0000005: Access violation writing location 0x00000000.
6850226E

68502258  or          eax,0C00h
6850225D  mov         dword ptr [esp+50h],eax
68502261  fldcw       word ptr [esp+50h]
68502265  fistp       dword ptr [esp+50h]
68502269  movzx       eax,byte ptr [esp+50h]
6850226E  mov         byte ptr [esi],al                   // esi content is 0
68502270  movzx       ecx,byte ptr [edi]
68502273  fldcw       word ptr [esp+54h]
68502277  imul        ecx,ebx
6850227A  mov         dword ptr [esp+50h],ecx
6850227E  fild        dword ptr [esp+50h]
68502282  fdiv        qword ptr ds:[68802D40h]
68502288  fadd        qword ptr ds:[68802D38h]
6850228E  fstp        qword ptr [esp]
68502291  call        687D5950

Call-stack:

    cvirte.dll!6850226e()     
     [Frames below may be incorrect and/or missing, no symbols loaded for cvirte.dll]    
     cvirte.dll!684d149c()     
     cvirte.dll!687b036c()     
     cvirte.dll!687b09c2()     
     cvirte.dll!684d9759()     
     cvirte.dll!684d9981()     
     cvirte.dll!687b5850()     
     cvirte.dll!687bc167()     
     cvirte.dll!687bd40f()     
     user32.dll!7674c4e7()     
     user32.dll!7674c5e7()     
     user32.dll!7674c590()     
     user32.dll!76744f0e()     
     user32.dll!76744f7d()     
     ntdll.dll!779c6fce()     
     user32.dll!76744ec3()     
     user32.dll!76741be4()     
     user32.dll!7673ffcd()     
     cvirte.dll!687c13c1()     
     cvirte.dll!68483419()     
     cvirte.dll!68722687()     
     cvirte.dll!68729882()     
     cvirte.dll!68525b8b()     
     cvirte.dll!686042a6()     
     cvirte.dll!6846d7dd()     
     cvirte.dll!68557bcc()     
     sw_dbg.exe!00402470()

[ulaf]

Couple of crucisal pieces of information related to the previous post:

the SW causes similar crash on Windows 7 32 and 64 bit versions.

The gradient background color is drawn on the second canvas which resides exactly

underneath the one causing the issue. The top canvas has tranparent background,

and the cursor is the only item drawn visibly on it.

[MilanR]

Hi ulaf,

Are you able to post a piece of example code and instructions that can be run to reproduce this behavior?

[D_Biel]

Could you also provide the specific version of the CVI Run-Time Enge you are using? You can find this by checking the DLL version at C:\Windows\System32\cvirte.dll or C:\Windows\SysWOW64\cvirte.dll. Right-click the DLL and choose properties from the context menu. You will find the version number of the DLL in the Details tab of the properties menu. With the specific version, we can check the map file to determine which function the RTE crashed in, which may or may not be helpful depending on which function it is.

[ulaf]

>    cvirte.dll!6850226e()     
     [Frames below may be incorrect and/or missing, no symbols loaded for cvirte.dll]    
     cvirte.dll!684d149c()     
     cvirte.dll!687b036c()     
     cvirte.dll!687b09c2()     
     cvirte.dll!684d9759()     
     cvirte.dll!684d9981()     
     ntdll.dll!76f76fce()     
This is the crash stack-dump after aprox. 30 minute the UnstableSample.exe run behind another window (programmers notepad window),

on a target machine with 32-bit Windows 7 version. cvirte.dll is a version which gets included when installation-package is

created. It also crashed on the development machine, 64-bit windows 7 (took significantly longer)l, indicating again "CanvasClear()" function.

cvirte.dll details:

Version: 10.0.1.434

Modified: 11/4/2011 10:00AM

Size: 4.86 MB

Attached is a minimized version of the problematic code: the part which is related to the instability, is not modified.

Just compile the project and run, bring another window belonging to a different software, in front of the Sample window, such that

the slider of the indicator (gradient colored) is almost covered, just a little of it is visible, and wait. I moved the covering window

left and back to the same position again few times every 5 -10 minute interval.

[D_Biel · Accepted solution]

Sorry for the delay in response. I followed a red herring for a few hours when troubleshooting this. Turns out this could have been solved much quicker by using the Resource Tracking in CVI. If you have the Full Development system, then you can change the Build Options >> Debugging Level to Extended and then open Window >> Resource Tracking. This will show you all of the memory and handles that your code currently has open. It will show when items are created, modified or destroyed. By viewing this while your application is running (you will have to suspend execution at a breakpoint to see the resource tracking), you will see that the program continues to create plots that belong to the COLORSCALE graph. That is your intensity graph. If you look at the function help for PlotIntensity, it reminds you in a note that a new plot is created each time you call this function and that you must dispose of these plots with DeleteGraphPlot.

You can add something like this in InitScaleData.

if(plotHandle != 0)
{
        DeleteGraphPlot (IndicatorPanel(0), IND_COMP_COLORSCALE, plotHandle, VAL_DELAYED_DRAW);
}
plotHandle = PlotIntensity (IndicatorPanel(0), IND_COMP_COLORSCALE, scaleArray, 2, OGL_SCHEME, VAL_DOUBLE, gColorMap,gColorMap[OGL_SCHEME-1].color, OGL_SCHEME, 1, 1);

I don't think you are necessarily running into a memory issue here by not disposing the plots. Instead, intensity plots use a few GDI handles. In Windows Vista and 7 the number of GDI handles is restricted to 10000 by a Windows registry key. Watching the number of open GDI handles in process explorer reveals that 10000 handles were open when the application crashed on my system after about 45 minutes of execution.

Let me know if this works when you get a chance to try this solution.

[D_Biel]

In addition to this, you should take a look at the Color Ramp Settings for the Numeric Slide control. This allows you to convert a slide control into a color scale like you have implemented with the intensity plot and canvas. You may not be able to get it to look exactly like what you have created, but it might suit your needs and will be easier to maintain and less resource intensive. You can also configure it programmatically at run-time using the Color Ramp Functions library.

[ulaf]

My appologies not trying the solution out sooner, some other project was at very high priority.

I was able to verify that numerous plots were created and not released, using resource tracking,

which appears to be extremely useful tool.

Your suggested solutions are workable. Thank you.

[ulaf]

Would it be possible to remove the simplified project sources (zip archive) from this posting?

[D_Biel]

I sent an email to our moderators to remove it.