Built app bad menu refnum bug

[Tropo]

LabVIEW 2011.

I have this LabVIEW template which I use whenever starting a new programming session
It among others, contains an empty menu reference which I check regularly.
Originally I used to initialize this reference at program startup.
One day I decided that I don't bother to set this reference when I do not use the menu system when running the program.
So far so good. One program I had made, worked perfectly when polling this empty reference too.
Then I built an application of this program, and this application also worked perfectly well.
I even left it running on idle (250 ms loop) doing almost nothing for days just because it was no reason to close it until next use.

Though by accident I one day had a look into my temp folder and saw some LV text logfile of quite some size, like 250 MB.
The beginning of that log file looked like this:

####
#Date: 9. feb 2012 13:06:22
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: QuickPlot
#Version: 11.0f2 32-bit
#AppKind: AppLib
#AppModDate: 02/06/2012 15:17 GMT
#LabVIEW Base Address: 0x30000000


09.02.2012 13:06:23.491
DWarn 0xACE16152: CallIsARefnumFunction : bad refnum kind = 9
e:\builds\penguin\labview\branches\2011patch\dev\source\objmgr\OMRefnumSupport.cpp(51) : DWarn: CallIsARefnumFunction : bad refnum kind = 9
minidump id: dde0e1e2-4980-48c5-bffb-de98be10a344

0x30074773 - lvrt <unknown> + 0
0x307D2E50 - lvrt <unknown> + 0
0x30672298 - lvrt <unknown> + 0
0x30628C9C - lvrt <unknown> + 0
0x041AA76C - <unknown> <unknown> + 0
0x046C9258 - <unknown> <unknown> + 0
0x3090DB00 - lvrt <unknown> + 0
0x0000E8EC - <unknown> <unknown> + 0

... and repeating...

Of course, the item that drew my attention is the line saying: "CallsARefnumFuncion: bad refnum kind=9"

Through some investigation I finally found out that that warning was due to the checking of the empty menu reference.
Every 250 ms the LV runtime system hit that reference and added some lines to that log file.

I feel this must be some kind of bug since that this only happens when running a built application, not when only running the development system program.
And of course it's an annoying bug if that log file gets a chance to grow GB big an maybe crash a whole computer.

[mikeporter]

What was the name of the file?

Mike...

[Tropo]

It is

QuickPlot_32_11.0_XXXXX_cur.txt

where XXXXX ist my Windows logon name.

Now that I have fixed that flaw by setting the menu reference, the file content just stays unchanged like this:

####
#Date: 28. feb 2012 15:55:17
#OSName: Windows 7 Ultimate Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: QuickPlot
#Version: 11.0 32-bit
#AppKind: AppLib
#AppModDate: 02/28/2012 14:55 GMT
#LabVIEW Base Address: 0x30000000
 

[mikeporter]

I assume that you don't have the error cluster output from the menu vis connected. If so, try wiring it to something like the edge of a structure or something - it doesn't matter what - and see if it makes a difference.

Mike...

[Tropo]

Yes I have the error cluster wired, but that is actually irrelevant.

What I forgot to mention is that the only way I check the reference is by wiring it to the Not a Number/Path/Refnum?-function which is then wired to a case structure. If the refnum is not set, nothing is done. If the refnum is real, the Get Menu Selection-function is executed.  During the bug-situation the refnum is non-existent (i.e. not set), and so the Get Menu Selection-function is not called.

So what is causing the logging of those warnings to that file is merely the Not a Number/Path/Refnum?-function.

[smercurio_fc]

Do you have a simple project that someone else can use to replicate the situation?

[Tropo]

It's simple as this.  LabVIEW 11 executable and VI and LV8 VI.

[smercurio_fc]

Actually, that was precisely what I had created when I asked the question if you had a sample project, since I was not able to replicate the situation. I created an application out of it, and I did not see a file being created. Where is this file being created? You said the "temp" folder. Which "temp" folder. There's like a dozen different ones.

[Tropo]

My default user temp folder in Windows 7:

C:\Users\MY-USER\AppData\Local\Temp

File: Menu ref bug_32_11.0_XXXXX_cur.txt

where XXXXX is my Windows logon ID

Content:

####
#Date: 28. feb 2012 18:15:57
#OSName: Windows 7 Ultimate Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: Menu ref bug
#Version: 11.0 32-bit
#AppKind: AppLib
#AppModDate: 02/28/2012 17:15 GMT
#LabVIEW Base Address: 0x30000000



28.02.2012 18:15:57.896
DWarn 0xACE16152: CallIsARefnumFunction : bad refnum kind = 9
e:\builds\penguin\labview\branches\2011\dev\source\objmgr\OMRefnumSupport.cpp(51) : DWarn: CallIsARefnumFunction : bad refnum kind = 9

0x30074473 - lvrt <unknown> + 0
0x307D3130 - lvrt <unknown> + 0
0x306720D8 - lvrt <unknown> + 0
0x306282EC - lvrt <unknown> + 0
0x041B4D7F - <unknown> <unknown> + 0
0x014C8B78 - <unknown> <unknown> + 0
0x3090D900 - lvrt <unknown> + 0
0x0000E8EC - <unknown> <unknown> + 0

and repeating... 

[smercurio_fc]

I was able to replicate the situation. Looks like debugging code that was left into the LabVIEW Run-Time. Doesn't seem to happen with other types of references, but I did not do an exhaustive check. I would agree that this is a bug.