What is memory.cpp at line 1038?

We have been running the same test in LabVIEW for a few years. Now all of a sudden, we are starting to get a memory.cpp error at line 1038. The test normally runs days at a time (~2 weeks), but we are getting this error after about 18-24 hours. Any ideas of what could cause this? Could this be caused by any Windows XP hotfixes? We are using LabVIEW 7.1 on a windows xp machine.

I've already checked out that particular site for info. And we do open and close files in our tests. And we do have quite a few loops. But it has worked with no issues for a few years and much longer time spans (and also more open/close files and loops). So after the error occurred on our only two machines (with exact set up) that run LabVIEW 7.1 (the rest are still on 6), we rolled one back to a date before all of the hotfixes occured and we have had no problems since. The second machine had an issue with rolling back so IT came and reinstalled XP. The problem is that they install an updated version and we cannot install an older one. It has Service Pack 3 in it and I think there are some hotfixes that came along with it that are the source of the problem. But I can't gaurantee it. Hopefully we'll figure it out soon.

Similar Messages

How to resolve Error #3: memory.cpp, line 563

I moved my application to a new computer with Windows XP and installed Labview 6.1 from the installation disc. When I run Labview 6.1, it allows me to open a project but, as soon as the project loads it shows the following error message (Error #3: memory.cpp, line 563). I deleted dir.mnu as suggested but the problem persists. The application runs fine on the old computer. I even uninstalled and re-installed Labview 6.1 on the new computer with the same result. What do I do now?

I'm sorry, I'm the one that was confused... You are having a FieldPoint problem, yes?
First make sure that the FP VIs are not stored as part of your appliction code. If it is, delete it. Next, if you don't already have them, install the latest version of the FP drivers. If you have only the latest version of teh drivers installed and you are still getting crashes, this sounds like an NI problem.
The sort of problem you are running into is but one of many reasons for not saving code from the vi.lib as part of your application code.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Error #3: "memory.cpp", line 639; VI used to work, now it stopped

Hello,
I am running LabVIEW 6.0.2. I have a rather complicated VI that used to work just fine. I have run it a bunch of times without any problems. I have not changed anything at all, and now it gives me Error #3: "memory.cpp", line 639 every time I run it. Does anybody know what could have happened?
Thanks,
Corey

Corey,
Not without seeing the code.
Perhaps there is some memory leakage going on, or open references that cannot be resolved.
Also, check your memory to make sure it is still working (view your RAM amount).
Other possibilities include possible conflicts with software running in the background, or software you recently installed.
Check your task bar, and make sure your virus protection and anything else unecessary is off. These can eat memory and processor time.
Other than that, navigate to the site where the bug tells you to (don't remember off the top of my head) and report it to NI.
Good luck

"Fatal internal error:"memory.cpp",line 593"

I need some help.
Can some please explain what i am doing wrong here. i have created a Dll from a LV 7.0 vi. The header file looks something like this:
typedef struct {
long dimSize;
double elt[1];
} TD2;
typedef TD2 **TD2Hdl;
typedef struct {
double f0;
double df;
TD2Hdl magnitude;
} TD1;
void __cdecl Spectrum(double freq, double amp, TD1 *Spec);
And i have the following code where i allocate memory and attempt to call 'Spectrum':-
TD1 *Power;
double frequency=10, amplitude=1;
Power = (TD1 *) malloc(sizeof(TD1));
(*Power).magnitude = (TD2**)malloc(sizeof(TD2));
*(*Power).magnitude = (TD2*)malloc(5000*sizeof(TD2));
(*Power->magnitude)->dimSize = 5000;
for (i=0; i<500;
i++) {
(*Power->magnitude)->elt[i] = 0;
Spectrum(frequency, amplitude, Power);
I keep getting Fatal internal error: "memory.cpp", line 593" when it tries to call Spectrum. I believe i have allocated memory correctly although i may be wrong. (I was getting 'exception' errors before). The VI i used to create the Dll contains a basic 'Function Generator' (sine wave) and a 'Power Spectrum'.
I have looked at the Knowledge base and dll examples that come with LV 7.0 and have tried setCINArray and NumericArrayResize but have not had any luck. It seems like the documentation is for LV 6.0 and 6.1.
Has anybody seen this or have any idea why i am getting this?
Thanks

> Can some please explain what i am doing wrong here. i have created a
> Dll from a LV 7.0 vi. The header file looks something like this:
>
> double frequency=10, amplitude=1;
> Power = (TD1 *) malloc(sizeof(TD1));
> (*Power).magnitude = (TD2**)malloc(sizeof(TD2));
> *(*Power).magnitude = (TD2*)malloc(5000*sizeof(TD2));
>
> (*Power->magnitude)->dimSize = 5000;
>
> for (i=0; i<500; i++) {
> (*Power->magnitude)->elt[i] = 0;
> }
>
> Spectrum(frequency, amplitude, Power);
>
> I keep getting Fatal internal error: "memory.cpp", line 593" when it
> tries to call Spectrum. I believe i have allocated memory correctly
> although i may be wrong. (I was getting 'exception' errors before).
> The VI i used to create the Dll contains a basic
'Function Generator'
> (sine wave) and a 'Power Spectrum'.
> I have looked at the Knowledge base and dll examples that come with LV
> 7.0 and have tried setCINArray and NumericArrayResize but have not had
> any luck. It seems like the documentation is for LV 6.0 and 6.1.
>
It looks to me like you are constructing arrays to pass to LV using
malloc, instead of the labview.lib functions for creating or resizing LV
array handles.
You should refer to the manual on Calling External code for details on
the construction of an array.
Greg McKaskle

Internal error: "memory.cpp", line 593 with PXI 8175

Hi,
I have created a program with Labview RT 7.0 which makes acquisition, storage and display of data with PXI controllers 8175.
I used Datasocket for the data display on a deported computer.
Because of the number of the Datasocket tags used, instead of sending values all the time, I'm sending value for the deported computer only if the user needs to see it.
For example : if the user needs to see data, so only Datasocket tags for data display will be active, and if the user needs to see parameters values, so only parameters datasockets tags will be active. And, if the display program is in "standby" mode, almost all datasocket aren't active.
So when the user needs to see data values, he opens the data values window of the display program, and then, the datasockets tags for data value are now active, but : sometimes at this moment, the PXI stops with an "internal error "memory.cpp" line 593"!
The only solution is to manually reboot the PXI, the programmatically reboot doesn't work in this case of error. But it is far away from the displaying computer.
The error happens regularly after a 2 weeks period of standby. So I though about a memory overflow, I checked all the arrays, and none of them is growing to the infinity.
If someone knows about this problem, I will be very happy to learn about how to get rid of it!!!
Best Regards,
G Liagre
Best regards,
G Liagre

Hi Rob, Hi Matthieu,
Thank you for your reply.
I found in the database many reply about this error, but none of them were helpfull for me.
I tryed your link to the knowledge data base, but the error described there is for dll association in LabView and interface nodes.
I didn't used any interface node in my code.
The problem is that I cannot test my program on the PXI because I don't have access to it rightnow (only by remote desktop, and with a 56k modem..)
Let me give you a part of this huge code.
I suspect this part of the code to be the one which create the problem, but it's not sure.
If you find something obviously wrong, tell me!
Best regards,
G Liagre
Best regards,
G Liagre
Attachments:
Communication.zip ‏931 KB

Error #3, "memory.cpp", line 865(V6.0) 876(V6.0.2)

I used a VI one day with no problems, and the next I got this message - "Error #3, "memory.cpp", line 865" I did not even close the VI or modify it an anyway.
I was first running Labview V6.0 and tried upgrading to V6.0.2 but the error continued (now on line 876). I also tried recompiling and backup copies of the VI and SubVIs, which did not work either. A suggested fix is to delete "dir.mnu", which likewise did nothing.
To me it looks like the problem rests in the Labview "Copy" command, which I use to copy a file to another directory, because when I delete it it works fine again.
Any suggestions would be greatly appreciated!

Hello,
It seems that while copying your file, memory is filling up too quickly for LabVIEW to clean it up and it's crashing LabVIEW. View the memory usage in the Task Manager to confirm this.
LabVIEW Internal Errors (Failure in XXX.c / XXX.cpp at line YYY)
If the Copy function is not the cause of the error, about 95% of the time, the next step is to look for DLL nodes or CIN nodes. The likely culprit is that a string or array is being handed to the C code, which either overwrites memory, or leaves the array/string data structure to an inconsistent state leading LV to overwrite memory. Anyway, this is a very common cause.
If you eliminate that possib
ility, the remainder are usually some sort of corruption saved in the VI, but normally those will not even load.
To simplify it before submitting it to support, please try executing individual subVIs and see if the problem is limited to a particular VI or a smaller set of VIs.
Zvezdana S.

[4712] WARNING!!! 'Huh, you set a test object to itself... whats up with dat?' Line 601 in function in file .\tstobj2\ObjArray.cpp

I'm using TestStand 4.0 and anytime I try to intialize my chasis this message shows up in my debugg viewer. I would appriciate any feedback. I have no idea what could be triggering this message or why it's worded the way it is.
[4712] WARNING!!! 'Huh, you set a test object to itself... whats up with dat?' Line 601 in function in file .\tstobj2\ObjArray.cpp

You've hit what was intended to be an internal development warning, but apparently the warning macro used is not compiled out in the release.
This has likely been there since TestStand 1.0 and is nothing to worry about. In most cases it indicates you've called SetPropertyObject or SetPropertyObjectByOffset to set an object that was already set in the specified location. This is a harmless NOP and the warning only appears in attached debuggers, but it "might" be an indication that you have made a programming error.
I launched and exited the 4.0 sequence editor without seeing this warning, so I don't know if it is being triggered by your code module (or sequence, or custom step type, or custom UI, or custom process model, ...) or another part of TestStand that you are using. Chances are good that this warning does not indicate a functional problem. However, if you can reproduce it with a clean uncustomized TestStand install, I'd like to know how you did it.
I've entered a corrective action request to remove this warning.
Message Edited by James Grey on 09-13-2007 10:12 AM

DDR3 Memory Standards: Blurry Lines

DDR3 Memory Standards: Blurry Lines
Rated speed, JEDEC, XMP, EPP, overclocking, overvolting... and what it all means
Much confusion has dawned upon many new users. Purchasing memory is not as easy as it used to be. Manufacturers have forced belief that their modules run at certain DDR3 standards. However, what they don't tell you is that these standards [1866, 2133] do not exist. You're required to overclock, modify timings, and overvoltage the memory modules that have these manufacturer rated speeds. So when you plug your memory into your computer and boot it up for the first time, do not expect 1600+ speeds the first time around. You'll at least have to enable XMP/EPP and/or manually configure (timing and voltage) settings in the BIOS.
Now this is where things start to get complicated and full of numbers:
JEDEC:
JEDEC is an industry memory standard specification. Manufacturers comply with the JEDEC standard by programming the JEDEC profiles into the SPD chips on the memory. The highest SPD profiles you will find on the market right now are DDR-1333 (some are DDR-1600, but DDR-1333 is the main). This is because the latest Intel CPU platform [Sandy Bridge - P67] doesn't support higher than DDR-1333. This will change in the future, as Ivy Bridge supports DDR-1600 I believe.
EPP (Enhanced Performance Profile):
EPP is NVIDIA's higher-level SPD programming extention. NVIDIA's nForce chipsets can read this SPD extention to provide the much desired "one click overclock." Change a setting and wala, auto-overclocked memory.
XMP (eXtreme Memory Profile):
XMP is Intel's version of EPP that runs on Intel chipsets.
NOTE: EPP and XMP have 2 requirements: your memory MUST have an EPP/XMP profile, and your chipset MUST support XMP/EPP. There are no exceptions to this rule.
The point of all this confusion, and why the manufacturers do it
The most obvious question is why do the manufacturers do all this? Because they want to make more money. The bigger numbers on the sticker means bigger sales.
You would wonder why JEDEC have allowed Intel and NVIDIA to decimate their standard with their "extensions", but nonetheless this is what we're stuck to dealing with.
Example scenarios
Example 1:
You bought a P67 board, 2600k and some DDR-2133 memory. You build the computer to find that the memory isn't running at its manufacturer's rated speed (2133), so you take the first step: enabling XMP (this is an Intel chipset, remember) in the BIOS. However, your memory lacks the XMP profiles in its SPD chip so you can't change the setting. You would then consult the manufacturer's website for the settings to be used.
Example 2:
You visit the manufacturer's website, and consult their specified timings for your memory. I've chosen Corsair's Dominator GT 2133C9 in this case (>link here<). If you go to the tech specs section, you shall notice that the SPD speed is 9-9-9-24, DDR-1333, 1.5V which is a JEDEC standard. Corsair's "tested" speed is 9-10-9-27, DDR-2133, 1.65V* which is not a JEDEC standard, but is programmed with DDR-2133 as an XMP profile.
What this tells us is that these are DDR-1333 modules overclocked to DDR-2133 and programmed with an XMP profile to support that without manual adjustment. The actual speed of the module is DDR-1333, but the manufacturer's rated speed is DDR-2133. Like I said previously, manufacturer's rated speeds require at least entering the BIOS and either; enabling XMP, or manually configuring timings, voltage and speed.
If you bought the Corsair modules and tried to run them on an AMD Phenom II system, you would have to input the timings, voltage and speed manually because AMD chipsets do not support XMP. This is a common misunderstanding among many AMD-related visitors of the forum.
Summarising post and final thoughts
To summarise:
- The JEDEC standard of DDR-1333 is currently the highest support on Intel's Sandy Bridge platform. Therefore, whether your memory has regular SPD profiles for DDR-1600+ or not, it will NEVER be set at those speeds.
- Understanding the difference between JEDEC standards and manufacturer's rated speeds. The best hint would be look at the voltage. *JEDEC standards will always be 1.5V or lower; never 1.65V or higher.
- For your memory to work at its manufacturer's rated speed out the box you must; 1) have an XMP/EPP compatible chipset, and 2) have XMP/EPP profile(s) on the memory.
- AMD users will be unable to take advantage of XMP's convenience since their chipsets do not support it. They will have to set their settings manually.
I hope that this has explained a lot of things to some people, and increased their understanding.
Thanks for reading.
Another question to ask yourself: do you really need more than DDR-1333 to begin with? Find some answers and draw your own conclusion - >> P67 & RAM Performance -or- Why DDR3-1333 RAM is enough -> Save the money! <<

Quote from: Bas on 31-May-11, 23:57:20
@doubleohseven, you may want to read this before making more statements that involve lawyers and such: >>Please read and comply with the Forum Rules.<<
Further more, you are totally on the wrong track.
1. The memory controller is INSIDE the CPU, as such the CPU is the engine of your car.
2. The memory controller is GUARANTEED by Intel (AMD is about the same) to do 1333.
3. Memory is the tire of the car, it needs to be fast enough, but if the engine fails to do that speed the tires will NEVER reach their rated speed.
4. The motherboard is the chassis of the car, it provides mounting points but it doesn't power the car.
5. The harddisk is the trunk of the car, it determines how much load you can carry/store
6. The videocard is the windscreen and wipers of the car, the bigger they are the more details you see in gaming
7. The PSU is the petrol-tank of the car, use a too small one and your machine stops way before reaching your target.
Maybe now you have a clue that you are on the wrong track?
Sadly people don't do their homework before buying stuff, as such they do not know what they are buying and end up frustrated because they think something is wrong.
Ram is just 1 component....there is also more to a car then just a tire.
No, actually I think I am pretty much on the right track. Yes the memory controller on the CPU is 1333. But if you read the OP, you can see that what he describes (and what I found out) is that the chips on our RAM are actually 1033, 1333, and sometimes 1600 chips, overclocked from the factory to the speeds you buy and pay for ("What this tells us is that these are DDR-1333 modules overclocked to DDR-2133 and programmed with an XMP profile to support that without manual adjustment. The actual speed of the module is DDR-1333, but the manufacturer's rated speed is DDR-2133. Like I said previously, manufacturer's rated speeds require at least entering the BIOS and either; enabling XMP, or manually configuring timings, voltage and speed."). Therefore, this can cause instability with the system, I believe if the chips on the RAM were actually at the speeds advertized (1600, 1866, 2133), we would have a much greater chance (of course not 100% guaranteed because of the CPU) of running at those speeds. If the CPU was strictly what is limiting the RAM, wouldn't EVERYBODY on a Sandy Bridge system not be able to get their RAM up to 2133, because I AM seeing plenty people do you. The CPU may be ONE factor, but the RAM not having the chips on board at advertized speeds is another factor.
As for the lawsuit, seriously... I was just venting, it was more of a rhetorical statement, being angry about the RAM issue. If you have a problem with the post, please delete it.

I am trying to set an open DNS using the MacAir. But when I tried to flush the existing one at utilities/terminal, it will not work. I am using Yosemite. May I know what should be the command line so that I can shift to an open DNS? Thanks

I am trying to set an open DNS using the MacAir. But when I tried to flush the existing one at utilities/terminal, it will not work. I am using Yosemite. May I know what should be the command line so that I can shift to an open DNS? Thanks

>SystemPreferences>Network>DNS

How do I get out of kernel panic? kernel panic upon boot. I did that hard drive cleanup and reinstalled Lion. What about memory? Anyone think I need to upgrade my memory? I have 8gig.

I get kernel paic upon boot. I did that hard drive cleanup and reinstalled Lion. What about memory? Anyone think I need to upgrade my memory? I have 8 G of upgraded RAM. (20 inch iMac core 2 duo)

If you're able to boot, launch the Console application in any of the following ways:
☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)
☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.
☞ If you’re running Mac OS X 10.7 or later, open LaunchPad. Click Utilities, then Console in the page that opens.
Select the most recent panic log under System Diagnostic Reports. Post the contents — the text, please, not a screenshot. For privacy’s sake, I suggest you edit out the “Anonymous UUID,” a long string of letters, numbers, and dashes in the header and body of the report, if it’s present (it may not be.) Please don't post "shutdownStall" or "hang" reports.
If you can't boot in the usual way, try a safe boot. The instructions provided by Apple are as follows:
Be sure your Mac is shut down.
Press the power button.
Immediately after you hear the startup tone, hold the Shift key. The Shift key should be held as soon as possible after the startup tone, but not before the tone.
Release the Shift key when you see the gray Apple icon and the progress indicator (looks like a spinning gear).
During startup, you’ll see a progress bar, and then the login screen, which appears even if you normally log in automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin.
Safe mode is slower than normal, and some things won’t work at all.
Note: If FileVault is enabled under Mac OS X 10.7 or later, you can’t boot in safe mode.

Windows LV6.0 running on Linux Wine: config.cpp error (line 404)

Have anyone tried to run LabView (Windows version) under Linux using the Wine "emulator"?
Trying this on Debian Woody, with a Win98 install of LabView 6.0 returns:
config.cpp error (line 404)
I tried to search for such a file on both Win/Linux partitions: there's none.
So how am i gonna check this line 404?
Any clue would be strongly welcome!

I agree with Labviewguru about getting Labview for Linux. The only
problem is that you have to dish out $2000 or $3500. They don't have a
Base package.
I'm not sure if NI recomends a particular window manager but I do know it
will run on any of them. In an extreme case I used it on a PII 233MHz,
64MB ram, and a 300 MB disk. It was a Slackware distro using the fvwm2
window manager. Ran great. Presently I run it with Gnome.
My point is that if you have to buy a LV for Linux license, at least you
can save money buy putting it on a machine that's been used as a paper
weight for several years.
-kevin
In article <[email protected]>,
"Labviewguru" wrote:
> I don't believe you can run LabVIEW in an e
mulation environment. There
> is too much system control that LabVIEW needs a handle on to be able to
> run on an emulator.
>
> The reason you are not able to find and troubleshoot that file is
> because it is part of the source code for LabVIEW, and doesn't exist
> except in a super secret vault which may or may not be located in Austin
> Texas...
>
> Are you aware that there is a version of LabVIEW for Linux? I believe
> that they recommend running KDE or similar GUI, but check on the support
> website for that at ni.com/linux.
>
> I hope that was enough of a clue...

What is the best on line bill pay software for mac

What is the best on line bill pay software for the Mac. I just switched over from Windows and now realize Quicken for Mac doesnt have on-line bill pay (which in 2013 seems amazing to me). I really dont care about any of the other features in Quicken beside the bill pay feature, so if anyone has any recommendations, it would be most appreciated. Thanks.

Most banks have purely website based bill pay systems. I would ask your bank if they have one. Those are more compatible, and more secure than third party systems. If they are browser specific, then they are not secure.

Good morning, I have the following problem. I can not start Adobe Muse on my computer because I get a box Assertion Failed in file "... \ src \ ape \ DOMFontProvider.cpp" at line 482: numFontadded = = 1 Doregisterfont fail to add font. Check museapp \ he

Good morning, I have the following problem. I can not start Adobe Muse on my computer because I get a box Assertion Failed in file "... \ src \ ape \ DOMFontProvider.cpp" at line 482: numFontadded = = 1
Doregisterfont fail to add font. Check museapp \ hello \ resources for missing files

Are you still facing the same issue ? if yes then please post the screenshot of exact error and few details such as if you are getting this error while opening a specific file or on double click on Muse itself ?
Thanks,
Sanjit

See whats taking memory

Hi,
I own a Lumia 900 and yesterday I noticed that I am using about 14GB of my 16GB memory, I synced my phone and migrated all my videos. Now it only uses 10GB of memory which still is too much.
I just want to know if there is a way to see exact details of whats taking memory, most of my applications I don't use as frequent as others and I just want to know the amount each app is using so that I know what to remove and what to keep instead of going on an uninstall spree and hope for the best.
So is there a way to do this, without jailbreaking/unlocking/rooting the device?

Hi dahaka7,
It's good to remove all applications that you do not use, as they may use surprisingly a lot of space on your device, especially if they are caching content or creating detailed log files. In addition to pictures, videos, applications, music and games. your phone has the operating system on the phone memory, which will reserve some of the space.
I am afraid there is no tool that will enable you to see how much space a certain application reserves, but you can see how big the installation file is before you download it. Some games especially can be rather large, up to several hundred megabytes. So the xBox tile is a good place to start if you are looking to free up some space.
Hope this helps,
Puigchild
If you find this post helpful, a click upon the white star at bottom would always be appreciated.
If it also solves your problem, clicking ACCEPT AS SOLUTION below it will benefit other users!

What is the gray horizontal line under the times in the timeline?

What is the gray horizontal line right under the times across the top of the timeline? It has a little orange beginning and ending tab.

That is the Work Area Bar.
Unfortunately the search option in the Help is broken (again).
Most people (I think) have turned it off.
But for instance you can drag the bar over an area you want to preview.

What is memory.cpp at line 1038?

Similar Messages

Maybe you are looking for