I have a "not enough memory to complete this operation"...
kramer
(with no error code) with tcp/ip Vi's. Also screen does not refresh.
I have a "not enough memory to complete this operation" error message
(with no error code)
with tcp/ip Vi's. Also when this message occurs, the User interface
of the Labview programs
does not refresh anymore. I just click Ok and everything seems to be
back to normal.
We have a server that uses a for loop to scan an array of Tcp/ip
refnum and read each connections
for 20ms before going to the next one (obviously we leave each
connections open for a long period of time).
The clients open a connection and can send or receive data to/from the
server.
Everything is working well but the problem always occurs after a
couple hours of execution (between 1 and 5 hours).
I am using labview 6.0.2 with Win 98 SE. The problem occurs in the
build application as well as in the code.
I have already tried to change to execution system to UI with no
effect and I also disabled multithreading in the labview
options but I still have the same result. Can anyone help me quick !!!
Thanks
Eric Dallaire
VibroSystM Inc.
Brian Vibert
You should be able to use the profiler to see which vi is using up the
memory.
Brian
kramer
Ben
Could you post the server code? We may be able to see something that
could help. Otherwise I will be forced to do a lot of wild
speculating.
Willing to help,
Ben
Dave Korpi
Have you figured out what has happened?
Have you isolated the lack of refreshing with the error?
I have seen similar things with NT and think it could be what Ben syas
about filling an array... Have looked but not with the profiler...
Need to have connection to the machine when this happens. The problem
I see is intermittent and has at times "gone away" after re-starting.
Let me know what you find if you have fixed it!
My e-mail is ko...@starband.net
Thanks,
Dave
kramer
close to it. The problem seems to be caused by concurrence between my
tcp/ip write and tcp/ip read Vi's. When I use the profiler or any
other memory tools, I see that my memory stays very stable and does
not fill up at all. The message saying "not enough memory to complete
this operation' seems to be incorrect as it is not a memory error. I
can now reproduce the problem sending only one tcp/ip packet from the
client to the server. I think the problem is caused when I close a
connexion to a client in my server and I try to read at the same time
on the listener I just closed (cause this is done in separate thread).
Still need to do more tests ... Send me any feedbacks if you have any
clues or solutions !
Thanks
Eric
Dave Korpi
Please refer to the following thread:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000123C0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0
for the same problem description. We have a few open reference numbers
on this. We do not have a solution and it seems to be pointing to the
manner in which LabVIEW processes tcp/ip in WIndows NT and not Win 9X.
Any rebuttal to this?
Please refer to the other thread...
Thanks,
Dave Korpi
Dave Korpi
Please refer to the following thread:
for the same problem description. We have a few open reference numbers
on this. We do not have a solution and it seems to be pointing to the
manner in which LabVIEW processes tcp/ip in WIndows NT and not Win 9X.
Any rebuttal to this? Anyone know "who" owns the error report "Not
enough memory to complete this operation" It is not in anything I can
find in LabVIEW... I think it is Windows NT...
Melissa Garrity, a super support tech at NI, has Reference number
401456 open for me on this... Please help on this very important
issue.
Please refer to the other thread mentioned above...
Thanks,
Dave Korpi
kramer
from Labview. I will soon post a VERY simple code that demonstrate the
problem ... It comes from the Tcp/ip read an Tcp/write functions ...
and it does'nt seem to be a memory error.
Dave Korpi
Waiting for your post by golly... Here is what I have found so far...
Looks like Windows from where I am looking..
In the end just want to find the source of the problem and fix it by
golly!
Here you go:
Melissa and Stephane:
Thanks for the reply Melissa.
Stephane...
Does look like the error comes from Windows. Also looks like there is
someone at NI who knows about special issues having to do with NT
related to "flooding" This is why Melissa gave the example in the
server. Therefore, the following conclusions to be validated by all:
1) I feel the problem comes from some specific "bug" in Windows NT
that does not exist in Windows 9X. I think it is related to speed but
need to have an exact answer to give customers.
2) The source of the problem is in the SERVER and not the CLIENT. I
need this verified. If this is true it looks like we only have to
determine a delay period to put in the exact right place in our
server. I think it needs to be between the LISTEN and the WRITE. Some
of the delay can be taken up by whast we are writing (for example an
analog data acquisition might take 10 of the needed 25 milliseconds).
The exact number of milliseconds is not known.
3) We need to understand, and get clear confirmation on the exact
source of the problem (who is complaining) and what "routine" caused
the complaint (the server in this case?)
My plan of action is to use the Simple Data Server and Simple Data
Client that Melissa refered to and put a control in place of the 25
millisecont constant, build executables of these two and run them on
an NT. I will then adjust the 25 millisecond control up and down to
see if reducing it causes the "not enough memory..." error and if I
increase it we have it go away...
If this comes to pass then we will know there is a relation to the
delay and to the error.
Thanks,
Dave Korpi
THis means that I need to select the proper test code to send to
Melissa.
Dave Korpi
22642 Indian Springs Road
Salinas, CA 93908
Phone: (831)-455-0418
Fax: (831)-455-0419
e-mail: ko...@starband.net
----- Original Message -----
From: <Sup...@ni.com>
To: "Dave Korpi" <ko...@starband.net>
Sent: Wednesday, March 06, 2002 8:09 AM
Subject: Re: (Reference#401456) Phone Support E-Mail
Note: Your reference number is included in the Subject field of this
message. It is very important that you do not remove or modify this
reference number, or your message may be returned to you.
Hi Dave,
I've been following the different discussion threads to see if they
can
provide any insight. The response by Eric was interesting, but
doesn't
seem to be the cause of Stephane's problem...does it sound like yours?
I
was thinking that it may have something to do with a connection being
closed, and then doing a read/write to that connection. This should
definitely produce the "not enough memory" error. This doesn't seem
to be
Stephane's issue either, but maybe it is happening on your system.
Another thing I found that was interesting is in a TCP/IP Example that
ships with LabVIEW. Take a look at the "Simple Data Server.vi"
Example.
(You can find it by going to Help>>Search Examples>>TCP/IP>>Simple
Data
Server) In the block diagram it says "Delay 25ms so we don't flood
input
queue on PC's running NT" This phrase makes me think there is
something
special about NT (which we obviously know already!). Do you have some
sort
of delay in your program to compensate for this flooding? If you do
currently have a delay, what happens if you increase that delay time?
Let me know if any of these things apply to your particular issue.
I'll
continue to research this in case the above suggestions don't help.
Regards,
Melissa Garrity
boxer
length more than four the same problem occurs.
Douglas De Clue
> Yes. If the packet length is one, the system crash, but with packet
> length more than four the same problem occurs.
Possibly somewhere down in the code perhaps in National Instrument's
TCP/IP VI's themselves, from time to time an attempt is being made to
read or write an array or access an array index with a negative number
of bytes or a negative array index. The error message you are
describing sounds very similar to the message you get if you try to
dimension an array with a negative number of elements. Because of
ones-complement math, A -1 index becomes 0xFFFFFFFF about 4.2 billion
if treated like an unsigned number. When something tries to create an
array this large it will generally crash.
Doug D.
dde...@bellsouth.net
Slava Thereshin
> A -1 index becomes 0xFFFFFFFF about 4.2 billion
> if treated like an unsigned number. When something tries to create an
> array this large it will generally crash.