I have a "not enough memory to complete this operation" error message (with no error code) with tcp/ip Vi's. Also screen does not refresh.

[kramer]

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 probably are letting a buffer or array continually fill with data. You should be able to use the profiler to see which vi is using up the memory.

Brian

[kramer]

Nope, the memory is very stable ...

[Ben]

Hi Kramer,

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]

Eric:

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 korpi@starband.net

Thanks,

Dave

[kramer]

I still have not fully figured out what is happening but i'm getting 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]

Hi all!

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

lorpi@starband.net

[Dave Korpi]

Hi all!

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? 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 th
e other thread mentioned above...

Thanks,

Dave Korpi

korpi@starband.net

[kramer]

the problem occurs in Windowns 9x/Me and Nt/2000 and definitly comes 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]

Kramer:

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: korpi@starband.net

----- Original Message -----
From:
To: "Dave Korpi"
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