general protection fault executing a CVI discard function

[Inomed]

Hi,

I changed my developing environmet from CVI 8.5 to CVI 9.0.1 and there were few linking errors regarding an equal function name in the external library "setupapi.lib" and in toolbox.obj, although CVI 8.5 could build the project without any problems. I could manage an error free linkage by choosing the new "setupapi.lib" from CVI90\sdk\...

Now I can compile and link my software project. But unfortunately it comes to a runtime error if I run the application:

FATAL RUN-TIME ERROR:   "EPCascade.c", line 2530, col 13, thread id 0x00000F5C:   The program has caused a 'General Protection' fault at 001B:00421366.

This error occures everytime at the same address if any CVI-"discard"-function is executed. It concerns e.g. "DiscardCtrl()" and "DiscardPanel()" functions. I checked if creating and discarding functions are executed in the same thread - it is really so, so it is not a problem.

Could there be an inconvenience regarding CVI discard functions in CVI 9.0.1? What could be the solution?

Many thanks for any suggestion!

[nickb]

Hello Inomed,

I was not able to reproduce the issue you are seeing with CVI 9.0.1.  It sounds like you can reliably reproduce what you are describing - can you post some code that will exhibit the behavior so that I can reproduce the issue?  Also - are you controlling any ActiveX servers using the controller wizard to generate an fp for your project?  If so, what server(s) are you controlling?

Thanks!

NickB

National Instruments  

[Inomed]

Hello NickB,

unfortunatelly I cannot post you an example: the project is simply too big..

In meantime I could bring it to run without the fatal run-time errors: before a discard-function is called, I remove the appropriate callback function (Why did it worked with CVI 8.5.0?). It works fine for the DiscardCtrl(). But if I have to discard a panel which has a lot of controls and child panels that have also many controls, then I remove all callbacks of this main panel and its child panels. And this causes a new problem with the non fatal run-time errors (-13 and -4), if I create a new panel.

My guess is that when I remove all the callbacks something is missing then. So, probably, I have to remove only the dynamically created callbacks. Can I somehow see if a callback function was generated dynamically?

To your question about ActiveX:

Yes,  this are "VideoCapX" and "VirtuelleHeadBox". The last one is our own ActiveX server.

Thank you for the your reply!

[nickb]

Hello Inomed,

There is another approach we may be able to take to find a solution for this issue.  If you could generate a crash dump for you application by doing the following, we may be able to quickly come to a solution for what you're seeing:

Windows XP

1. Run C:\Windows\System32\drwtsn32.exe and ensure the "full" crash dump type is selected

1. Run C:\Windows\System32\drwtsn32.exe -i (this will register Dr. Watson as your "just in time" debugger)

2. Whenever you get a crash and you see the "Please tell Microsoft about this problem..." dialog, click "Don't Send"

3. Browse to the C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson folder.  The dump and log files are there.  The .dmp file is the important file for our concerns.  Keep in mind that if you have a second crash, it will overwrite the previous dump.

Windows Vista

Dr. Watson is not available in Vista, so perhaps the best option is just to use windbg:

1. Install the Windows Debugging Tools. (note, if using 64 bit Vista, be sure to install the 64 bit version)

2. Run C:\Program Files\Debugging Tools for Windows\windbg.exe -i (this will register windbg as your "just in time" debugger)

3. When you get a crash, windbg should start up automatically.  At that point, in to its command window type .dump /ma C:\temp\mydump.dmp to generate the dump file. 

Once you have a .dmp file you will need to upload it to our ftp site at ftp://ftp.ni.com/incoming - because it will be very large.  Once you have done this, if you could reply to this forum and let me know the name of the .dmp file you have uploaded, I will copy it down and take a look.

Thanks!

NickB

National Instruments  

[Inomed]

Hi NickB,

I followed your instructions and uploaded the crash dump to the ftp location you gave me. The name of the file is "Inomed_crash_dump.dmp".

Thank you!

[nickb]

Hello Inomed,

For some reason, I am unable to find the file you mention.  Can you verify that the file was indeed able to post to ftp://ftp.ni.com/incoming?  Thanks!

NickB

National Instruments  

[nickb]

Hello Inomed, 

Shortly after I posted, I found the file you put up.  It may have just taken a little while to upload.

The dump seems to indicate that the crash may be occuring somewhere in our toolbox code.  It's hard to be more specific because I don't have (nor is there really any way to get) debugging symbols for your executable.  However, because the Programmer's Toolbox is open source, you should be able to attach the source to your project, and hopefully find the place in which the crash occurs.  To do this, you will need to follow a couple steps:

1. If the Programmer's Toolbox is in your Libraries, you need to remove it by going to the Library menu, selecting Customize, and then in the bottom box selecting ...\toolbox.fp and clicking the Cut button. You will then need to restart CVI

2. Once you have done this, you will need to add toolbox.fp to your project.  To do this, browse to <National Instruments>\CVI90\toolslib\toolbox\ and drag toolbox.fp into your project.

3. Once toobox.fp has been added to your project, you should then be able to see it also added under the Instruments tree.  Right click on Programmer's Toolbox in the Instruments tree, select Edit Instrument, and then click the Attach and Edit Source button.  This will allow you to place breakpoints and step into toolbox.c, and should also hopefully show us the crash location.

 

4. Run your program in debug mode from within the CVI environment.  If my suspicions are correct, your program should now crash in toolbox.c somewhere.  

Please let me know if any of these steps give you trouble, and what the results of these steps are.

Thanks!

NickB

National Instruments  

Message Edited by nickb on 06-10-2009 01:34 PM

[Inomed]

Hello NickB,

thak you for the fast reply!

I could debug toolbox.c as you suggested. It is really so that the crash occures in the toolbox module. Please, find attached the screenshot of the CVI-debugger. 

Thank you!

[Inomed]

Hello NickB,

I think I know now the source of the problem! This are the callbacks for the tool tips. If some tool tips are generated with SetCtrlToolTipAttribute() then by discardig of this panel or control it will crash. I removed now the tool tips with the same function SetCtrlToolTipAttribute() before discarding the panel, so the tool-tip-callbacks created by CVI are also removed. 

In this way I can run my application without any run-time errors. But there apperently are some differences between CVI 8.5.0 and CVI 9.0.1 regarding this.

Thank You NickB!

Best Regards

[ryk]

I know this is a little late, but your previous posts helped me to find the following when I experienced similar behaviors, so thought I would post this solution to help others that might have the same problem.

Regarding Tooltips and DeleteCtrl

I have confirmed that the problem with deleting my LED control was indeed tied to the SetCtrlToolTipAttribute functions.  Because of the memory allocations, including that of a pointer to callback that are installed as a result of using these functions, simply deleting the control for which the SetCtrlToolTipAttribute was used to modify, is not a good option.  Documentation describing the behaviors I have seen are not easily (if at all) found within the function panel help for this class of function, or anywhere else that I have looked so far.  By experimentation however, I found that the following sequence of code fixed the problem:

SetCtrlToolTipAttribute (panelHandle, led[ii].ctrl_hnd, CTRL_TOOLTIP_ATTR_TEXT, "");
//SetCtrlToolTipAttribute (panelHandle, led[ii].ctrl_hnd, CTRL_TOOLTIP_ATTR_ENABLE, 0);
DiscardCtrl(panelHandle, led[ii].ctrl_hnd);

I confirmed that all that is needed to prevent a failure within the toolbox.fp files is to send an empty string as the tooltip attribute text for the control that is to be deleted, before deleting it.  I originally included setting the ENABLED attribute to 0, but found that not necessary.