Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Previewing Items in a Send Queue

Was there ever a resolution of this issue or at least some more information regarding its root cause.

We are currently seeing this exact same behavior on our project which doesn't use the Actor Framework but also runs with lots of dynamically launched VIs and user event for communication.  The keyword "VILinkObjRemoveCore" found in the dump does not seem to be very frequent on the forum.  Similarly, we are using LV 2011 SP1 and there is no issue in the development environment but it is easily reproducible (though not always) in the run time environment.

Thank you!

0 Kudos
Message 11 of 20
(2,095 Views)

Olivier: LV R&D *thinks* we have it addressed in LV 2014. By addressed, I mean that we have not tracked down what is causing our unloader to enter the bad state, but we now can detect the bad state and set things right again without crashing out. You would need to join the beta program at ni.com/beta to try it out.

0 Kudos
Message 12 of 20
(2,095 Views)

Aristos,

I've done quite a bit of reading on this forum and LAVA since Monday and found other similar issues related to the actor framework.  Because this issue is fairly recent in our case, I would expect that recent changes in our code and its execution has something to do with the problem. 

I would appreciate if you could comment on a few things to help us address the issue immediately as this application is currently shipped to customers, waiting 6 months to build in 2014 is far from ideal and patching it with the "Quit LabVIEW" doesn't seem really clean and may hide other potential issues in the code.

  1. If this is the same error as you mention, you are suggesting that neither LV2012 nor LV2013 resolve the issue?
  2. Is there a CAR with public details about the issue that we can read about to understand what is happening?
  3. One strange thing is that the VI mentioned in the crash report (in lvlog.txt) has not been modified recently.  Is the VI mentioned in the log after "#** VILinkObjRemoveCore:" the real cause of the issue?  I believe that most of the time LVRT reports the error, that VI has not even exectued.

Thank you!

--- Crash log ---

####

#Date: Mar-25-14 3:27:22 PM

#OSName: Windows 7 Professional Service Pack 1

#OSVers: 6.1

#OSBuild: 7601

#AppName: ---Removed for post ---

#Version: 11.0.1f2 32-bit

#AppKind: AppLib

#AppModDate: 02/14/2014 20:35 GMT

#LabVIEW Base Address: 0x30000000

25/03/2014 3:39:46.000 PM

Crash 0x0: Crash caught by NIER

File Unknown(0) : Crash: Crash caught by NIER

minidump id: 10e65032-542b-404d-a4c6-00608c6e1421

ExceptionCode: 0xC0000025’ N

0x3072D464 - lvrt <unknown> + 0

[... A lot more line almost identical...]

0x30650A57 - lvrt <unknown> + 0

*** Dumping Bread Crumb Stack ***

*** LabVIEW Base Address: 0x30000000 ***

#** VILinkObjRemoveCore: "[Full path of file goes here...]

*** End Dump ***

0 Kudos
Message 13 of 20
(2,095 Views)

Oliver: There is no public CAR because we found this coming in through the NI Error Reporter and we have no idea what causes it. Yes, 2012 and 2013 both occassionally have this issue. We have never isolated causing it. What we have done in 2014 is "assume this happens... how can we recover?" When we detect that something has gone off the rails, we do some work to put it back in place.

The VI mentioned in the log did go wrong -- something tried to kick it out of memory when something else still needed it. It is likely something above it in the hierarchy (not a direct caller, but something higher up) that is somehow doing the wrong thing. Do you have a panel or VI Ref that you used to keep open that you now close programmatically that uses this VI in its hierarchy? Did you change the order that a set of VI Refs are closing? Did you start opening/closing library/class refnums that you didn't used to use?

I really don't have much to offer you here. If your code replicates this crash reliably and you can share your code, please open a support ticket with ni.com/support and ask an AE to start working on identifying the source of the crash... that may help find a workaround.

0 Kudos
Message 14 of 20
(2,095 Views)

Hi Aristos,  We managed to resolve the issue internally.  Here is a brief description of what we believe the issue was and its resolution.  I hope that this allows NI to recreate it internally and resolve.  However, now that is done here, I can say that in our case, it was directly caused by our code and can therefore be fixed with better programming.  It would be nice if the error message was more relevant though!  In our application, we have one main user interface which launches many subVIs dynamically in the background and some of those subVIs are "managers" launching many more VIs dynamically.  At any given time, there is at least 6 of those VIs loaded in sub panels of the main VI and some of those VIs themselves include sub panels filled with other VIs.  All the VIs are launched using the "RunVI" method with "False" wired to "Auto Dispose Ref".    In one specific part of our code, the references of a group of VIs were not closed properly.  All of those VIs were definitely stopped before the top level VI completed its execution and closed its front panel, forcing LVRT to clean up and stop the process.  Along with closing the references, we also made sure to remove every VI from the sub panels before terminating the execution of the application.  Both of those things together resolved our issue and the "VILinkObjRemoveCore" error seems to be a thing of the past.  I assume that wiring "True" to "Auto Dispose Ref" could also solve the issue as you do not need to explicitly close the references.  One interesting thing is that the VI reported by NI crash reporter had nothing to do with the VIs which references were not closed properly.

0 Kudos
Message 15 of 20
(2,095 Views)

A)  I am very glad you've found a fix.

B) I would still appreciate you opening a support ticket, if you're willing to share your code with National Instruments. It would help us fix the problem for other users.

0 Kudos
Message 16 of 20
(2,095 Views)

I know that it would be very helpful for NI in order to address this issue but unfortunately, sharing the code will not be possible at this point.

0 Kudos
Message 17 of 20
(2,095 Views)

Hi all

I came up to this thread by the lvlog.txt with the entry VILinkObjRemoveCore.

My Labview development environment is crashing when I try to close the project. The lvlog.txt says:

####

#Date: Mo, 1. Sep 2014 12:31:44

#OSName: Windows 7 Professional Service Pack 1

#OSVers: 6.1

#OSBuild: 7601

#AppName: LabVIEW

#Version: 13.0.1f2 32-bit

#AppKind: FDS

#AppModDate: 04/02/2014 12:19 GMT

#LabVIEW Base Address: 0x00400000

starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3492412307.62307450, (12:31:47.623074532 2014:09:01)]

starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3492412307.62307450, (12:31:47.623074532 2014:09:01)]

starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3492412307.62307450, (12:31:47.623074532 2014:09:01)]

starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3492412307.62307450, (12:31:47.623074532 2014:09:01)]

starting LabVIEW Execution System 4 Thread 0 , capacity: 24 at [3492412754.54976270, (12:39:14.549762726 2014:09:01)]

starting LabVIEW Execution System 4 Thread 1 , capacity: 24 at [3492412754.54976270, (12:39:14.549762726 2014:09:01)]

starting LabVIEW Execution System 4 Thread 2 , capacity: 24 at [3492412754.54976270, (12:39:14.549762726 2014:09:01)]

starting LabVIEW Execution System 4 Thread 3 , capacity: 24 at [3492412754.54976270, (12:39:14.549762726 2014:09:01)]

starting LabVIEW Execution System 3 Thread 0 , capacity: 24 at [3492412754.83379080, (12:39:14.833790780 2014:09:01)]

starting LabVIEW Execution System 3 Thread 1 , capacity: 24 at [3492412754.83379080, (12:39:14.833790780 2014:09:01)]

starting LabVIEW Execution System 3 Thread 2 , capacity: 24 at [3492412754.83379080, (12:39:14.833790780 2014:09:01)]

starting LabVIEW Execution System 3 Thread 3 , capacity: 24 at [3492412754.83379080, (12:39:14.833790780 2014:09:01)]

starting LabVIEW Execution System 7 Thread 0 , capacity: 24 at [3492412754.85379310, (12:39:14.853793145 2014:09:01)]

starting LabVIEW Execution System 7 Thread 1 , capacity: 24 at [3492412754.85379310, (12:39:14.853793145 2014:09:01)]

starting LabVIEW Execution System 7 Thread 2 , capacity: 24 at [3492412754.85379310, (12:39:14.853793145 2014:09:01)]

starting LabVIEW Execution System 7 Thread 3 , capacity: 24 at [3492412754.85379310, (12:39:14.853793145 2014:09:01)]

starting LabVIEW Execution System 8 Thread 0 , capacity: 24 at [3492412754.85779330, (12:39:14.857793332 2014:09:01)]

starting LabVIEW Execution System 8 Thread 1 , capacity: 24 at [3492412754.85779330, (12:39:14.857793332 2014:09:01)]

starting LabVIEW Execution System 8 Thread 2 , capacity: 24 at [3492412754.85779330, (12:39:14.857793332 2014:09:01)]

starting LabVIEW Execution System 8 Thread 3 , capacity: 24 at [3492412754.85779330, (12:39:14.857793332 2014:09:01)]

starting LabVIEW Execution System 9 Thread 0 , capacity: 24 at [3492412754.86179400, (12:39:14.861793995 2014:09:01)]

starting LabVIEW Execution System 9 Thread 1 , capacity: 24 at [3492412754.86179400, (12:39:14.861793995 2014:09:01)]

starting LabVIEW Execution System 9 Thread 2 , capacity: 24 at [3492412754.86179400, (12:39:14.861793995 2014:09:01)]

starting LabVIEW Execution System 9 Thread 3 , capacity: 24 at [3492412754.86179400, (12:39:14.861793995 2014:09:01)]

Thread consumption suspected: 2 Try starting 4 threads

starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3492412914.51775790, (12:41:54.517757893 2014:09:01)]

starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3492412914.51775790, (12:41:54.517757893 2014:09:01)]

starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3492412914.51775790, (12:41:54.517757893 2014:09:01)]

starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3492412914.51775790, (12:41:54.517757893 2014:09:01)]

Thread consumption suspected: 8 Try starting 4 threads

starting LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3492412914.63176920, (12:41:54.631769181 2014:09:01)]

starting LabVIEW Execution System 2 Thread 9 , capacity: 24 at [3492412914.63176920, (12:41:54.631769181 2014:09:01)]

starting LabVIEW Execution System 2 Thread 10 , capacity: 24 at [3492412914.63176920, (12:41:54.631769181 2014:09:01)]

starting LabVIEW Execution System 2 Thread 11 , capacity: 24 at [3492412914.63176920, (12:41:54.631769181 2014:09:01)]

Thread consumption suspected: 2 Try starting 4 threads

starting LabVIEW Execution System 2 Thread 12 , capacity: 24 at [3492412914.69077490, (12:41:54.690774918 2014:09:01)]

starting LabVIEW Execution System 2 Thread 13 , capacity: 24 at [3492412914.69077490, (12:41:54.690774918 2014:09:01)]

starting LabVIEW Execution System 2 Thread 14 , capacity: 24 at [3492412914.69077490, (12:41:54.690774918 2014:09:01)]

starting LabVIEW Execution System 2 Thread 15 , capacity: 24 at [3492412914.69077490, (12:41:54.690774918 2014:09:01)]

Thread consumption suspected: 12 Try starting 4 threads

starting LabVIEW Execution System 2 Thread 16 , capacity: 24 at [3492412914.74978110, (12:41:54.749781132 2014:09:01)]

starting LabVIEW Execution System 2 Thread 17 , capacity: 24 at [3492412914.74978110, (12:41:54.749781132 2014:09:01)]

starting LabVIEW Execution System 2 Thread 18 , capacity: 24 at [3492412914.74978110, (12:41:54.749781132 2014:09:01)]

starting LabVIEW Execution System 2 Thread 19 , capacity: 24 at [3492412914.74978110, (12:41:54.749781132 2014:09:01)]

Thread consumption suspected: 16 Try starting 4 threads

starting LabVIEW Execution System 2 Thread 20 , capacity: 24 at [3492412914.80878690, (12:41:54.808786869 2014:09:01)]

starting LabVIEW Execution System 2 Thread 21 , capacity: 24 at [3492412914.80878690, (12:41:54.808786869 2014:09:01)]

starting LabVIEW Execution System 2 Thread 22 , capacity: 24 at [3492412914.80878690, (12:41:54.808786869 2014:09:01)]

starting LabVIEW Execution System 2 Thread 23 , capacity: 24 at [3492412914.80878690, (12:41:54.808786869 2014:09:01)]

<DEBUG_OUTPUT>

01.09.2014 14:36:33.170

DAbort 0x89B93EF0: bad image in ValidateImage

c:\builds\penguin\labview\components\LVManager\trunk\13.0\source\image.cpp(13855) : DAbort 0x89B93EF0: bad image in ValidateImage

minidump id: 064358ac-5b61-42ad-8b36-c6a05d13636a

$Id: //labview/components/LVManager/trunk/13.0/source/image.cpp#11 $

</DEBUG_OUTPUT>

0x006A3F43 - LabVIEW <unknown> + 0

0x10014DF0 - mgcore_SH_13_0 <unknown> + 0

0x00B60C0B - LabVIEW <unknown> + 0

0x00FBDAF1 - LabVIEW <unknown> + 0

0x00D091AD - LabVIEW <unknown> + 0

0x00F477F6 - LabVIEW <unknown> + 0

0x00F47885 - LabVIEW <unknown> + 0

0x0177EA03 - LabVIEW <unknown> + 0

0x01781A7F - LabVIEW <unknown> + 0

0x0171B068 - LabVIEW <unknown> + 0

0x0171C2E7 - LabVIEW <unknown> + 0

0x017085F3 - LabVIEW <unknown> + 0

0x01708A2F - LabVIEW <unknown> + 0

0x0170BCF4 - LabVIEW <unknown> + 0

0x01BE3109 - LabVIEW <unknown> + 0

0x01C86805 - LabVIEW <unknown> + 0

0x01BD785C - LabVIEW <unknown> + 0

0x01C03378 - LabVIEW <unknown> + 0

0x01C85DA4 - LabVIEW <unknown> + 0

0x01C025D1 - LabVIEW <unknown> + 0

0x0044A869 - LabVIEW <unknown> + 0

0x0044AC0D - LabVIEW <unknown> + 0

0x0044AC80 - LabVIEW <unknown> + 0

0x01DD2825 - LabVIEW <unknown> + 0

0x7520338A - kernel32 <unknown> + 0

0x77709F72 - ntdll <unknown> + 0

0x77709F45 - ntdll <unknown> + 0

0x00000000 - <unknown> <unknown> + 0

*** Dumping Bread Crumb Stack ***

*** LabVIEW Base Address: 0x00400000 ***

#** VILinkObjRemoveCore: "U:\LabView\DSI-Treiber\trunk\DSI_Treiber\Interface_vis\Read_sensor.vi"

*** End Dump ***

I am open to share the project. It my opinion everything in this project is legimitate and even more, i use nothing spezial, no Actor framework, no huge clusters nothing at all which seems to me weird..

0 Kudos
Message 18 of 20
(2,095 Views)

Hi urssieg,

It does not look like you are running into the same issues seen in this thread. VILinkObjRemoveCore is a common tag added to our lvlog files when we recognize that a particular VI might be causing an issue. I would recommend contacting NI Support to troubleshoot the specific conditions surrounding your crash and info included in your crash dump files.

Is this crash happening every time you close the project? Do the logs all call out the same VI?

Looking at the error called out in your log (DAbort 0x89B93EF0: bad image in ValidateImage), there are a number of issues that might be happening. I would start by checking the VI called out in your log (Read_sensor.vi). We have a instances of the DAbort logged involving attached objects and problems with VI icons, so try removing any arrows and replacing the VI icon if possible.

Zach P.

Staff Software Engineer | LabVIEW R&D | National Instruments
0 Kudos
Message 19 of 20
(2,095 Views)

Hi Zachmx

Thanks for the answer.

I thought it could be the same because my google search about the term VILinkObjRemoveCore showed only few hits.

Yes, it did crash everytime after I close the project and yes, its always the same vi. I have no arrows in my icons. What I did is: I copied the whole vi in a new vi, rebuild the conector pane and draw the vi icon.

Since  now, this project and all projects which incolaborates the packed library from this project has not any more crashed.

But I have other projects which crashed with a similair pattern.

My vi icon drawing has always the same patter:

Double click the filled rectangle. fill colour is white.

write a text on the left side into the boxes "Line 1 text".

Sometimes the written text touches the edges or its too big for the box.

and yes, I did contact NI support. They rebuild the library containing this read_sensor and it stopped to crash for the moment. But this was more a shortterm solution.

My problem is, I wasn't sure how to deal with the lvlog. Is the named vi really the culprit?

second... I had no clue what could be wrong with this vi.

0 Kudos
Message 20 of 20
(2,095 Views)