NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Is TestStand Large Address Aware?

Is TestStand Large Address Aware?

If so, how do I set this for my deployment sequence(SimpleUserInterface.exe), considering the /3GB or /PAE is enabled in the XP Windows Boot.ini?

 

Thanks,

 

Mobiux

0 Kudos
Message 1 of 12
(3,734 Views)

Hi Mobiux

 

The large address aware status is based on the environment used to compile the SimpleUserInterface.exe file you are using.  In the case of the LabVIEW and CVI versions, the UI will be large address aware if they were created in LabVIEW 8.5 or later; or in CVI 8.1 or later.  For TestStand 4.2 and later, the Interfaces are compiled in this version, but I would recommend opening the source for the UI you are using and recompiling just to be sure.

Al B.
Staff Software Engineer - TestStand
CTA/CLD
0 Kudos
Message 2 of 12
(3,692 Views)

What is the status for this in 64-bit TestStand 2014?

In an application, we observe that a TestStep using an external image processing library throws a system level exception; at this point, the private bytes of SeqEdit.exe have increased to 3.5 GByte. When using the library function standalone, it allocates approx. 12 GByte and runs fine.

Is there a known or presumed reason for such a behavior?

Regards

Peter

0 Kudos
Message 3 of 12
(3,235 Views)

Are you using 64-bit TestStand? If so then the large address aware flag should not matter. The amount of memory addressable in 64-bit TestStand should be the full amount of memory available on the machine. Running out at 3.5 GB is consistent with using 32-bit TestStand with large address aware enabled. If you need more memory than that, you should use the 64-bit version (TestStand ships with both a 32-bit and 64-bit version, make sure you are using the 64-bit one if you want to maximize the amount of memory available).

 

If the code you are calling is in an out of process server (for example via COM) make sure the out of process server you are using is a 64-bit one if you need lots of memory.

 

Hope this helps.

-Doug

0 Kudos
Message 4 of 12
(3,225 Views)

Thank you for the helpful clarification.

Yes, it is 64-bit TestStand and so are, of course, all DLLs involved. I will now investigate whether one of these has been built with /LARGEADRESSAWARE:NO and truncates pointers.

Thanks,

Peter

0 Kudos
Message 5 of 12
(3,218 Views)

@pwaszkewitz wrote:
[...]external image processing library throws a system level exception; [...]

What kind of system level exception is that?

Experience shows that there are multiple sources for system level exceptions. One being that the virtual memory of a process is "full". Another for instance is running out of heap space. Later issue can occur when handling tons of references, most likely connected to a reference leak.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 12
(3,215 Views)

Currently, the only information I have about the exception is the TestStand error number -17502.

I will try to find out more.

Thanks

Peter

0 Kudos
Message 7 of 12
(3,207 Views)

Apparently, I was on a totally wrong trail.

Memory was quite sufficient, depending on changes in image processing procedures we got system level exceptions in random places, indicating an erroneous pointer operation. After copying the original image and working with the copy, the errors vanished, so apparently, the original pointer became invalid at some point. We are still investigating this.

One question though: as far as I can see, TestStand documentation gives explanations for error codes -17500, -17501, but not -17502. Is there anything which can be deduced from that error code about the nature of the error?

Regards

Peter

0 Kudos
Message 8 of 12
(3,181 Views)

To further clarify, setting /LARGEADRESSAWARE:NO would not result in trucating any pointers. The addresses are really the same size either way, the only difference is whether or not memory allocations will be mapped to addresses in which the high-order bit is set. I think the only reason it's a setting rather than just always using as much of the address space as possible is because some programs (especially older ones) incorrectly assume the high-order bit in an address will never be used and use it to indicate other things. To keep such programs from malfunctioning when addresses with the high-order bit are being used, the OS doesn't use it by default.

 

As far as your question about -17502, if there are additional details, they will show up in the error description or message box that displays the error, if not, the most likely cause of the error is an access violation. If you attach to the process with a debugger like Visual Studio (with native debugging enabled) then you should be able to determine the type of exception if you can reproduce it while running in the debugger. In Visual Studio the output window will usually explain what exception occurred.

 

Hope this helps,

-Doug

0 Kudos
Message 9 of 12
(3,172 Views)

@pwaszkewitz wrote:

Apparently, I was on a totally wrong trail.

Memory was quite sufficient, depending on changes in image processing procedures we got system level exceptions in random places, indicating an erroneous pointer operation. After copying the original image and working with the copy, the errors vanished, so apparently, the original pointer became invalid at some point. We are still investigating this.[...]


Peter,

 

there are functions which 'move' the data in memory. When dealing with such functions, copies of references made before calling the function will get void once the function runs.

I don't know if NI Vision (or at least some specific functions from it) falls under that kind of category, but best practise recommend to use ref IN and ref OUT when available instead of a static reference which is passed around. I never had a situation where following that practise created an error (unless some stupid, self-implemented stuff....).

 

For the stated errors, TS is not directly the origin of the error. There are lots of possible reasons for these errors like invalid parameters (invalid handle for OS exception) or race conditions on shared resources. That is why TS does not add detailed information unless the code throwing the error does this (e.g. custom module with exception handling). However, in most cases, TS error reports the originating step of the error. Using that information, i usually start with double-checking parameter values, disabling the call to make sure it really creates the issue, ... .

Sorry that i don't have more information right now on this.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 10 of 12
(3,168 Views)