CAR #279915

[mcduff]

Got the following message in a LabVIEW crash file, "lvlog.txt".

conditions that caused CAR #279915 have appeared.

Since CARs cannot be searched, does anyone know what CAR #279915 is? I would like to avoid those conditions if possible. (So far my Googling has been unsuccessful, only showing images of sports cars.)

Thanks

mcduff

[mcduff]

Update: Maybe I should call NI.

I believe the issue has to do with subPanels, most likely a subPanel Reference in multiple places.

I want to know what VI is running in a subPanel, so I thought I try this simple fix.

My FGV get the subPanel's reference, then it uses that reference to see what the name of the inserted VI is. The problem I have is possibly a race condition, although my debug logs don't indicate it, where that subPanel reference is used elsewhere. For some reason LabVIEW doesn't like that, and starts throwing this into the crash report.

DWarn 0x4F94E02B: DisposeObjHeap: conditions that caused CAR #279915 have appeared

Getting rid of the FGV stopped all the errors. Will need to rethink my program.

mcduff

[mcduff]

Update 2:

According to NI Support,  Corrective Action Request (CAR) 279915 pertains to a SignalExpress crash that was fixed back in LabVIEW 2011.

The plot thickens ...

mcduff

[Darren]

Talk to NI Support again... that CAR pertains to a subpanel issue that just happened to manifest within SignalExpress. I bet the developer who included that DWarn as a band-aid for SigEx would love to get your code to reproduce the issue.

[mcduff]

Thanks. I'll see if I can can make something that reproduces it. The code is not finished now, and I removed the offending piece.

Basically

Here is how I started having the bug, along with some background:

1. I have a subpanel control on my Main VI. A loop that runs in my Main VI inserts/ removes the subpanel into the control.
   1. No problems with the above method.
2. I wanted to make my program a bit more efficient and for other use cases, I wanted to know what VI was currently running in the subpanel.
   1. I made a FGV global that had a copy of the subpanel reference, and read the name of the VI in the subpanel.
   2. For whatever reason, LabVIEW did not like this FGV. I started having crashes and incorrect readings from my FGV. Once I removed the FGV and stopped reading from it, no more problems.
   3. My guess is some race condition where the subpanel reference was read into two different places that LabVIEW didn’t like.
3. FGV attached as zip.
4. Workaround, keep all subpanel references in a single loop.
5. This is how I noticed the bug. I would run the attached FGV, before deciding whether to insert/remove a VI from a subpanel. If the VI was already in the subpanel, then no reason to remove and re-insert it. LabVIEW did not like that FGV as it would return a blank sometimes for a subpanel VI that was running.

mcduff

[mcduff]

Update 3:

Trying to make an example, but no luck so far. Maybe I should submit my code to the Rube-Goldberg thread instead.

One clue.

The error, or DWARN, only seems to occur with VIs that are started and stopped and inserted into a subpanel. VIs that are always running when inserted do not appear to have this issue.

My case was an "About" window. I inserted it into a subPanel, and use the run vi method. (It is a standard JKI State Machine). When finished, I stop the "About" window normally, no "Abort VI method", close its reference, and remove it. I will try to recreate something like that tomorrow, when I tried with VIs that were always running, no problems. Maybe there is a delay with closing references, garbage collection, etc.

mcduff

[mike_at_spacex]

Any resolution here?

I'm (likely) seeing the same issue.

[mcduff]

I haven't been able to make an example that reproduces the error.

Sorry.

mcduff

PS Any LabVIEW openings at SpaceX? 🙂

[FixedWire]

This has just reared its ugly head in a large application when adding in debug subpanels (deeply embeded panels). Removed them again & it's still there. Perhaps something is not getting closed.

This may be of help?

https://forums.ni.com/t5/LabVIEW/CAR-279915/td-p/4007590?profile.language=en

Here are my errors:

<DEBUG_OUTPUT>
16.05.2020 15:15:23.127
DWarn 0xD1048076: AppDomain is being destroyed but the Runtime AppDomain was not ref-counted to zero
e:\builds\penguin\labview\branches\2018\dev\source\dotnet\DotNetAppDomain.cpp(247) : DWarn 0xD1048076:
AppDomain is being destroyed but the Runtime AppDomain was not ref-counted to zero
minidump id: 0563a108-dc30-449e-bd46-eb4c16121ef7
$Id: //labview/branches/2018/dev/source/dotnet/DotNetAppDomain.cpp#1 $

[wiebe@CARYA]

I know this is an old thread... Still actual though.

AFIC, InsertedVI is evil.

It just doesn't work correctly, and should not be used. All sorts of weirdness will happen if you do use ir.

The returned VI ref is not a copy of the reference in the subpanel, it is the actual ref. If you close this ref, LV gets seriously messed up.

A simple example (LV20):

This will hang\lock the vi in the subpanel (it only has a control on it's FP, no code).

2nd run you get an error there's still a vi in the subpanel.

Even if the VIs aren't running, LV thinks the VI is in the panel (but it isn't visible).

The reference is closed automatically if the vi calling InsertedVI stops running:

So calling InsertedVI in a clone will almost certainly cause problems.