"a custom control callback raised an exception"

[gdargaud]

Hello all,

yes, there are several posts about this error message, but they are all pretty old (<2009) and the solutions didn't seem to work, so I'm starting a new thread.

I installed 2013sp1 last week and removed 8.5, 2010 and 2012 this morning. And now one of my projects won't compile. Other projects aren't impacted (I tested about 10 in two different workspaces).

When I compile, I get a popup box with "a custom control callback raised an exception" and it comes back as soon as I click it. I have to kill CVI. It's a project that compiled cleanly with CVI2012 (no warnings). I can open and save the UIR files with CVI2013, no problem. I also deleted the cws file, no change.

I generated a debug log (cleaned up a bit):

[ERROR] [NationalInstruments_Restricted::LicenseCommon::getAddOnRegistryInfo] [..\licmgr\LicenseCommon.cpp:83] Error reading licensing information from registry key 'SOFTWARE\National Instruments\CVI\13.0\AddOns\Real-Time'
[WARNING] [LWGetTreeItem] [..\james\ui_tree.c:1481] Err = -55
[WARNING] [ChainPanelCallback] [..\james\toolbox.c:584] Err = -45
[ERROR] [NationalInstruments_Restricted::LicenseCommon::getAddOnRegistryInfo] [..\licmgr\LicenseCommon.cpp:83] Error reading licensing information from registry key 'SOFTWARE\National Instruments\CVI\13.0\AddOns\Real-Time'
[WARNING] [CheckForAutoRecover] [..\james\AutoSave.c:376] Err = -101
[WARNING] [LWGetTreeItem] [..\james\ui_tree.c:1481] Err = -55
[WARNING] [WorkspaceFileProc] [..\james\jn_work.c:657] Trying to load current workspace UFR.
[ERROR] [NationalInstruments_Restricted::LicenseCommon::getAddOnRegistryInfo] [..\licmgr\LicenseCommon.cpp:83] Error reading licensing information from registry key 'SOFTWARE\National Instruments\CVI\13.0\AddOns\Real-Time'
[BUILD] [RunJamfileBuild] [..\jon\srctxtcc.c:3331] Building s:\nedm\AcqEDM_Project\AcqEDMv4\cvibuild.AcqEDMv4\Debug
[BUILD] [MonitorBuildProcess] [..\jon\srctxtcc.c:3644] ...found 248 target(s)...
[FATAL] [AddFunctionToFakeFp] [..\jon\srcbrowse.c:12459] Assertion failed: typeName

The last line gets duplicated every time I click the popup, so it's relevant.

[Johannes_T]

Hello gdargaud!

The error dialog generated by CVI is likely to be incorrectly caused by the fact that CVI is trying to generate documentation from your source files.

In order to determine the exact cause of this problem,

1. Can you confirm that your project is using source code documentation tags and that your project settings (Build » Target Settings » Generate help from source)?
2. If this is the case, can you mention the type of documentation that your project will output (HTML, XML)?
3. Can you provide a code snippet (either the actual one from your code, or one that is similar to yours), in which you can reproduce the error dialog? Around the areas of your function prototypes that have /// source code documentation tags?

Thank you!

[gdargaud]

Hello and thank you for looking into this.

Indeed, I disabled the HTML generation and it compiled fine. I also tried XML and it works, although I don't know what to do with the resulting XML file.

Here's a code sample showing how I use the triple slash comments, but this is not an example that crashes. I'm trying to pin it down but it's a big interdependant project, so I can't remove pieces easily:

///////////////////////////////////////////////////////////////////////////////
/// HIFN	Write to USB. Use the USB_WRITE shortcut macro instead
/// HIPAR	Endpoint / USB endpoint
/// ARRAY	Data
/// HIPAR	Data / Array to write
/// HIPAR	Count / Number of bytes to write
/// OUT		ErrorMsg 
/// HIPAR	ErrorMsg / Possible return error message
/// HIPAR	FunctionName / For debugging
/// HIPAR	Line / Line number for debugging
///////////////////////////////////////////////////////////////////////////////
static int UsbWrite(int Endpoint, char Data[], int Count, char *ErrorMsg, const char *FunctionName, const int Line) {
...
}

[Johannes_T]

Thanks for confirming this, gdargaud! A useful hint that I can provide at this moment, is that the code snippet which causes this, is using the ARRAY documentation tag. The function parameter corresponding to that ARRAY documented tag could be using some custom defined type (e.g. typedef).

[gdargaud]

I'm not sure if it's the right way to look at the problem: I have about 10 other projects that use the triple slash comments in similar ways, and none exhibit this lockup when I generate the documentation. So maybe there's something wrong with one of those lines (invisible control char, or weird syntax or something), but I haven't been able to isolate it yet.

If I comment everything (Ctrl-E) in my project except "main() {" and "}" it does generate the HTML doc without problem. But I cannot comment out part of the project and compile successfuly... And it's 30k lines...

[Johannes_T]

Hello gdargaud!

Have you had any luck in isolating the problem?

Thanks!

[gdargaud]

Well, since I'm currently working on seven simultaneous projects, and I still had the old HTML documentation and that nobody reads my documentation anyway , the answer is no: I simply disabled documentation generation and that'll do for now !

[Johannes_T]

If it's possible from your side (legal/technical), you could send us a minimal copy of your project, that we can use to reproduce the bug, so we can have one of our engineers examine the code, in order to determine the exact location that causes the problem and possibly come up with a workaround.

If this is possible, you can upload an archive on our incoming upload site: ftp://ftp.ni.com/incoming

Best regards!

[gdargaud]

Done, there's an AcqEDMv4.zip that produces the problem.

[Johannes_T · Accepted solution]

Hello gdargaud!

We've determined that the crash is due to a bug in the HTML generation in CVI.

The COV parameter definition parsed by the HTML generation mechanism, causes the instability in CVI:

static int FitETH(double (*COV)[4])

In order to avoid this bug in CVI, and still be able to use HTML generation with your project, you could do one of the following:

1. Define your parameter using exclusively a pointer.
2. Use typedef to separate the type declaration of the array from the pointer:
   typedef double *pDoubleT;
   static int FitETH(pDoubleT array[4]) { ... }

We've reported this bug under ID #467835.

I hope this helps!

Best regards!