memory is full - No Listeners on the GPIB.

[netta]

I am at the end of my teather and hope someone out there can shed some light on this...

I have a very large project based on Endevo's GOOP2. I have been building it using the application builder with only a small handful of VIs going into the executable itself and all the others going into a support directory (as recommended by other posts on the subject of memroy full errors). My build machine has 4Gb RAM so I can confidently say it is not running out of memory and yet about half way through the build it fails with the following error:

Error 2 occurred at Property Node (arg 1) in ABAPI Dist Chg and Save VIs.vi->ABAPI Dist Build LLB Image.vi->ABAPI Copy Files and Apply Settings.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: Memory is full.

=========================

NI-488: No Listeners on the GPIB.

Property Name: Help:Document Path

I've watched the task manager and there's plenty of free memory... oceans of it.

Also it's worth saying that the build does work on my laptop but fails in the same way on two other machines, all with >2Gb RAM.

Also, if I then quit labview and restart I get the dialog which says there was a failure and do I want to investigate... The lvfailure log generated contains numerous sections of the form:

.\manager\image.cpp(6627) : DWarn: You filled the image table

$Id: //labview/branches/Europa/dev/source/manager/image.cpp#47 $

Any suggestions would be very very welcome....

[MikaelH]

QUOTE (netta @ May 1 2008, 07:08 AM)

LabVIEW: Memory is full.

Hi

I have a couple of suggestions.

My first option would be to upgrade to EndevoGOOP3 class templates, using the GDS function "Convert Goop2 classes to Goop3...".

If you can send me the code, I can help you out in converting it.

I guess it's not a memory problem but if you're running LV 85, you could increase the memory from 2GB to 3GB for LabVIEW to use.

Since Windos normally limits an application to use only 2GB.

You do this by adding the /3GB swith in the c:\boot.ini file, like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect [b]/3GB[/b]

You could also try to build the executable with the "Enable debugging" mode on, if you are running LV8.5.

Cheers,

Mikael

[Rolf Kalbermatter]

QUOTE (MikaelH @ Apr 30 2008, 06:17 PM)

I guess it's not a memory problem but if you're running LV 85, you could increase the memory from 2GB to 3GB for LabVIEW to use.

No it's likely not really a normal memory error but the image.cpp error would indicate that the image manager somehow got his table of possible image IDs exhausted. Any image in LabVIEW is allocated as an entry in a table and I think the index into that table is really an uInt16. So the table can't get bigger than 65535 images. I can't say what might cause the application builder to create so many images during a build but maybe the GOOP geeks might have some ideas.

Rolf Kalbermatter

[netta]

QUOTE (MikaelH @ May 1 2008, 12:17 AM)

Hi

I have a couple of suggestions.

My first option would be to upgrade to EndevoGOOP3 class templates, using the GDS function "Convert Goop2 classes to Goop3...".

If you can send me the code, I can help you out in converting it.

I guess it's not a memory problem but if you're running LV 85, you could increase the memory from 2GB to 3GB for LabVIEW to use.

Since Windos normally limits an application to use only 2GB.

You do this by adding the /3GB swith in the c:\boot.ini file, like this:

[boot loader]timeout=30default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS[operating systems]multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect [b]/3GB[/b]

You could also try to build the executable with the "Enable debugging" mode on, if you are running LV8.5.Cheers,Mikael

Hi Mikael,I would very much love to upgrade to GOOP3 but our project is huge and I anticipate the upgrade to be quite involved. Amongst other things, our object model is dependent on the composite pattern and I gather there are issues related to that in the new version. Once we decide to bite the bullet on this, any help would be very very welcome.Also, we are currently in the progress of upgrading to LV8.5 but are having problems with MSXML (It's happy with DOMDocument but can't find XSLTTemplate... but that's a posting for another thread ).

So I guess until we successfully upgrade, my question is... you have any suspicions as to what may be the cause of a "memory full" which clearly isn't due to a lack of physical memory? The image.cpp error does indeed indicate something image related... vi icons?... front panels?... block diagrams?.... are there any ways of excluding these from the build?

Alternatively, as you mentioned this configurable memory limit in 8.5, do you know of any other artificial limits (in config in LabVIEW somewhere) which I may be hitting?

Ta lots,

Netta.

PS... forgot to mention we're on 8.2.1 at the mo.

[netta]

QUOTE (netta @ May 1 2008, 10:42 AM)

Also, we are currently in the progress of upgrading to LV8.5 but are having problems with MSXML (It's happy with DOMDocument but can't find XSLTTemplate... but that's a posting for another thread ).

OK... So I've managed to get the application running in 8.5 (Hurrah!) and so the next step was to try to build the project... It almost gets to the very end but then fails with the following error...

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 7 occurred at Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer.

=========================

NI-488: Nonexistent GPIB interface.Method Name: Save:Target Instrument

Does anyone know how to make labVIEW actually tell you which file it is that it can't find (since it clearly knows)?!?! We have thousands of VIs in our application and I can't see any way of finding out what the offending file is.

Please please help... I think I'm going to cry.

[netta]

QUOTE (rolfk @ May 1 2008, 08:17 AM)

No it's likely not really a normal memory error but the image.cpp error would indicate that the image manager somehow got his table of possible image IDs exhausted. Any image in LabVIEW is allocated as an entry in a table and I think the index into that table is really an uInt16. So the table can't get bigger than 65535 images. I can't say what might cause the application builder to create so many images during a build but maybe the GOOP geeks might have some ideas.

Rolf Kalbermatter

Hi Rolf,

I've just tried and failed to rebuild the project in 8.5 and get the same error after it crashes so your suggestion about the fixed-size image table seems to still exist...

c:\builds\penguin\labview\branches\Jupiter\dev\source\manager\image.cpp(6852) : DWarn: You filled the image table

$Id: //labview/branches/Jupiter/dev/source/manager/image.cpp#45 $

Is there any known way of telling labview to ignore the images eg. icons etc... since I only need front panels available in only a small handful of VIs (all the rest are purely background processing) ?

[Rolf Kalbermatter]

QUOTE (netta @ May 1 2008, 01:43 PM)

Hi Rolf,

I've just tried and failed to rebuild the project in 8.5 and get the same error after it crashes so your suggestion about the fixed-size image table seems to still exist...

c:\builds\penguin\labview\branches\Jupiter\dev\source\manager\image.cpp(6852) : DWarn: You filled the image table

$Id: //labview/branches/Jupiter/dev/source/manager/image.cpp#45 $

Is there any known way of telling labview to ignore the images eg. icons etc... since I only need front panels available in only a small handful of VIs (all the rest are purely background processing) ?

Front panels are not images. Icons are and so are glyphs such as what is used in for instance in the tree control or in the listbox as symbols. Also any bitmap you incorporate anywhere would use such an image ID.

Also front panels get removed by default when building an application and that front panel is not necessary. Front panels are necessary when they are configured to be ever shown, when it's a top level VI that is eventually invoked through VI server, when an explicitedly linked property node for a control is present on the diagram and maybe one or two other more esoteric situations. What I can't say at all is which VIs that make up a GOOP object will require their front panel to be present too. Quite likely there are certainly situations where a VI needs its front panel despite that you never will want to see that front panel at all.

Also while building an application those image IDs should not be constructed for the entire hierarchy if VIs somehow use them but instead they might be temporarely created during copying/compiling of VIs but then should get disposed and be reusable for other images. Not sure either if this is the real cause of your original error message. This is a DWarn, meaning it is not nice if this happens but it should not necessarely prevent LabVIEW from continuing with its task. It's just an image after all so the worst thing that can happen in normal use is that you see an empty area somewhere where you would expect an image of some sort. On the other hand it could be that at some point during the applciation build some function needs to create an image and if it does not get a valid ImageID it just bails out with said memory error, which is not really right but in a sense also not completely wrong.

Anyhow I do think there is a bug somewhere that under some very rare situations tries to create way to many images for some reason. I could not really imagine how one would get into so many pictures or are you happening to use one or more tree controls with many thousend different custom symbols?

Rolf Kalbermatter

[netta]

QUOTE (rolfk @ May 1 2008, 09:02 PM)

Anyhow I do think there is a bug somewhere that under some very rare situations tries to create way to many images for some reason. I could not really imagine how one would get into so many pictures or are you happening to use one or more tree controls with many thousend different custom symbols?

Rolf Kalbermatter

V Interesting... Unfortunately we're not really using anything even remotely image intensive. We do have a couple of activeX browser controls but again I wouldn't expect these to be anything to do with images.

It's quite possible that the image.cpp error and the build failure are completely unrelated. It's just that they have both started happening recently and they both seem to be related to memory issues which made me suspect a connection.

To add to this, I've just tried to rebuild with the debug option enabled following on from MikaelH's suggestion earlier on since I was also seeing the duplicate filename warning during the build but that has also just failed with the same "File not found" error. It would also be helpful if it told me which files it thought were duplicate names. It seems to indicate it is about to list them with a ":" but then no list is to be seen

Netta sad

[netta]

QUOTE (netta @ May 1 2008, 04:08 PM)

Please please help... I think I'm going to cry.

Well I had got it to build once in 8.5 but turned out it was a one-off fluke... When I tried again it failed and has been failing ever since with file not found errors. I've pared it back to the bare minimum and am gradually adding classes back in (that's GOOP2 classes) in the attempt to find what's going on. It seems that it will fail once and then I run the build again (no changes) and then it will succeed. Then I add in another class, it fails, then I try again (no change) and it succeeds.

I have already mass compiled the entire code set and it all compiles fine but it seems that there must be something else that the application builder is doing which "makes things better" so that it works on the second pass.

Of course this is only a hypothesis since I have no explanation as to why this happens (and it's not entirely predictable).

Any clues?

Also... In parallel, I'm still trying to build on 8.2.1 (since it used to build ok up until the latest source release which started failing with the "Memory if full" error... hence the attempt to upgrade to 8.5). So my assumption is that there is something in the latest source which is causing the problem. Again I've pared back to the previous source version which built ok and am gradually adding the new code to try to find the culprit. I've now started to get the following new and exciting error: "Fatal Internal Error: "prim.cpp", line 4851" which crashes LV.

Anyone seen this before?

:headbang: - wonder how long it'll take for the bruising on my forehead to heal?