Possible path leak, unable to purge elements of base

[zola_the_gorgon]

Our Labview 2012 SP 1 program runs to completion. However, when we close down the main panel after execution has finished, and it exits Labview, it crashes with an error report.

I have attached one of the crash reports. Here's the text from one of the crash report files:

####

#Date: 20 Mar 2014 18:26:45

#OSName: Windows 7 Professional Service Pack 1

#OSVers: 6.1

#OSBuild: 7601

#AppName: LabVIEW

#Version: 12.0.1f5 32-bit

#AppKind: FDS

#AppModDate: 09/10/2013 09:10 GMT

#LabVIEW Base Address: 0x00400000

<DEBUG_OUTPUT>

20/03/2014 18:41:30.868

Crash 0x0: Crash caught by NIER

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

minidump id: ef42f225-2da4-4a1a-8b0e-43f819a76f55

ExceptionCode: 0xC0000005û¥l;uÐ

</DEBUG_OUTPUT>

Possible path leak, unable to purge elements of base #0

Our program calls some of our own C++ libraries. They have been built into our software and running for well over a year without any trouble.

A few weeks back, we changed all of our library call nodes from “Run in UI thread” to “Run in any thread”. I have tried changing them all back to “Run in UI thread”. It doesn’t make any difference.

Any help with this problem will be greatly appreciated!

[Lewis_G]

I'm getting this too. LV 2012 built to exe.  It is a simple operator console with network streams and shared variables

It happens sometimes when I close the application.

[billko]

This is from the LV 2013 known issues:

153731

—

Unhandled Exception can occur if absolute path for system DLL used in CLFN

This issue has been known since LV 8.6.  Do you think it applies?  Sorry, this is the closest thing I could come up with.

[Ray.R]

I've noticed similar issues with LV2012SP1.  I think I reported it a few times...  Initially thought it was just me, but it turned out to affect others, too.  I was seeing this since LV2010.

It does not always happen.  In my case, it was using the development system.  The executables were fine.

Curiosity question:  are you using LVOOP?

[Lewis_G]

I'm using LVOOP for an event driven state machine (the command pattern).  You think it could be related to LVOOP?

This error is worrying because I can't reproduce it and I need to commision the system soon.

[Ray.R]

I cannot say that it is related to LVOOP, but I have seen this in every LVOOP project I have worked on.  The only way to know would be to write the exact same program as a non-LVOOP version.

However, I recall seeing this message soon after starting a new project and after creating the initial classes.  I think I sent the small / new project to NI for investigation.

So...  to answer your question....  it kinda looks that way..

However, the executables have been solid.  I have not had complaints from the clients about unusual crash at the end of their run.  The software runs tests that can last a week (or more).  There are 3 or 4 different clients have code that use LVOOP. 

The error is not something that I have been able to reproduce...  It just happens.. Mostly when closing the project.  Occasionally when running the code or trying to run the code.  I should pay more attention to the behavior.  😉

[S.MNV]

Hi,

I'm getting this problem too. could you find any solution?

thanks

[joltie]

I see it too.  Happens in built app but only very rarely.  App uses Call Lib Function, but does NOT use full path, specifies kernel32.dll only without path.  Clueless as to the root cause.  Please help.

####
#Date: Thu, Jan 26, 2017 8:41:27 PM
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: U2C
#Version: 15.0.1f2 64-bit
#AppKind: AppLib
#AppModDate: 5/05/2016 14:18 GMT
#LabVIEW Base Address: 0x0000000030000000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 8 processors
InitExecSystem() call to GetNumProcessors()            reports: 8 processors
InitExecSystem()                                      will use: 8 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3568329687.08042860, (20:41:27.080428601 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
stopping LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3568329687.96327830, (20:41:27.963278294 2017:01:26)]
Possible path leak, unable to purge elements of base #0

[OctIng]

I've experienced the same problem even without a full path to the "kernel32.dll" but provided through the GUI interface text box of the call library node. Sometimes LabVIEW seems to modify the contents of this text box internally (I've seen seemingly random "..\..\<other.dll>" changes before, probably introduced because of path hierarchy changes).

We didn't experience any exceptions since we've specified the path on the diagram and removed it completely from the internal text box.

[Mehran_Moss]

This still happens in LabVIEW 2021!