Discussion:
Is memory still leaking?
(too old to reply)
Lew
2010-06-25 13:35:10 UTC
Permalink
VFP9/sp2 on W2003/sp2 server
I just modified an existing app to run indefinitely. It's a pole/parse/
report thingy, so its memory use is large when it finds and digests
large files, but small when quiet & not poling. I know there used to
be memory issues between earlier versions of VFP used for this kind of
app and the Windows servers leading one or both to eventually fail.
Thing is, I haven't kept up on these issues.

Are the gremlins still out there? What should I be watching out for?
JayB
2010-06-25 14:47:38 UTC
Permalink
hi Lew
I have not heard of or seen any memory leaky problems working with vfp9.
I have the webconnect server running 24/7 and I have no problems.
However, my webconnect is still running back on vfp6
jay
Post by Lew
VFP9/sp2 on W2003/sp2 server
I just modified an existing app to run indefinitely. It's a pole/parse/
report thingy, so its memory use is large when it finds and digests
large files, but small when quiet & not poling. I know there used to
be memory issues between earlier versions of VFP used for this kind of
app and the Windows servers leading one or both to eventually fail.
Thing is, I haven't kept up on these issues.
Are the gremlins still out there? What should I be watching out for?
Lew
2010-06-26 13:24:14 UTC
Permalink
Hey JayB:
I can now report a major failure with this combo. With the VFP app
doing its own poling for files (ie running continuously/poling for
work every 5 min), after 24 hrs it was allocating/releasing memory ok,
but by day 3 the server had given the app its max required allocation,
but wasn't grabbing it back when the app was quiet. We've solved this
problem by having the server's task scheduler run the app every 5 min
& having the app pole once & then exit. I'll have to change the
internal logic around a bit, but this is the solution we'll have to go
with. Too bad the fox couldn't do it by itself, I could have written
way more bells & whistles than the task scheduler can provide by
itself.
tg
2010-06-27 05:07:21 UTC
Permalink
Post by Lew
I can now report a major failure with this combo. With the VFP app
doing its own poling for files (ie running continuously/poling for
work every 5 min), after 24 hrs it was allocating/releasing memory ok,
but by day 3 the server had given the app its max required allocation,
but wasn't grabbing it back when the app was quiet. We've solved this
problem by having the server's task scheduler run the app every 5 min
& having the app pole once & then exit. I'll have to change the
internal logic around a bit, but this is the solution we'll have to go
with. Too bad the fox couldn't do it by itself, I could have written
way more bells & whistles than the task scheduler can provide by
itself.
Have you tried to reduce the allocated WorkinSetSize via API-Call ?
Should work, unles an internal vfp leak exists.

Have built a number of the above scenarios that kept on running,
but ran once into an internal leak. This I had to circumvent,
which was posible with this leak,

regards

thomas
Lew
2010-06-27 20:43:55 UTC
Permalink
I can't find any reference to the syntax for the WorkingSetSize api or
an example using it with VFP on the web. Can you point one out?
Thanks.
tg
2010-06-28 06:49:27 UTC
Permalink
Post by Lew
I can't find any reference to the syntax for the WorkingSetSize api or
an example using it with VFP on the web. Can you point one out?
Thanks.
If you google "setWortkingSetSize WINApi" you find a lot of hits,
including a blast from the past (2004) by me <g>

regards

thomas
Zootal
2010-06-27 22:04:49 UTC
Permalink
Post by Lew
VFP9/sp2 on W2003/sp2 server
I just modified an existing app to run indefinitely. It's a pole/parse/
report thingy, so its memory use is large when it finds and digests
large files, but small when quiet & not poling. I know there used to
be memory issues between earlier versions of VFP used for this kind of
app and the Windows servers leading one or both to eventually fail.
Thing is, I haven't kept up on these issues.
Are the gremlins still out there? What should I be watching out for?
I had a 24/7 app running with VFP7, and I gave up trying to find the memory
leaks. VFP is a huge c++ code base, and it is most likely still riddled
with obscure leaks.

FWIW, VFP is not well suited for running 24/7. It just isn't stable enough.
You need something to restart the app regularly, or at the least monitor it
for crashes. ServerDoc (www.serverdoc.com) works very well for that, and
I've used it for years. It's designed for game servers, but works well with
VFP. If the VFP app crashes (which it will do sooner or later), ServerDoc
very happily restarts it. It can also restart the app on a regular basis,
like every 24 hours or whatever interval works for you.
Jeff Grippe
2010-06-30 10:13:54 UTC
Permalink
Post by Zootal
Post by Lew
VFP9/sp2 on W2003/sp2 server
I just modified an existing app to run indefinitely. It's a pole/parse/
report thingy, so its memory use is large when it finds and digests
large files, but small when quiet & not poling. I know there used to
be memory issues between earlier versions of VFP used for this kind of
app and the Windows servers leading one or both to eventually fail.
Thing is, I haven't kept up on these issues.
Are the gremlins still out there? What should I be watching out for?
I had a 24/7 app running with VFP7, and I gave up trying to find the memory
leaks. VFP is a huge c++ code base, and it is most likely still riddled
with obscure leaks.
FWIW, VFP is not well suited for running 24/7. It just isn't stable enough.
You need something to restart the app regularly, or at the least monitor it
for crashes. ServerDoc (www.serverdoc.com) works very well for that, and
I've used it for years. It's designed for game servers, but works well with
VFP. If the VFP app crashes (which it will do sooner or later), ServerDoc
very happily restarts it. It can also restart the app on a regular basis,
like every 24 hours or whatever interval works for you.
Jeff Grippe
2010-06-30 10:16:52 UTC
Permalink
Post by Zootal
You need something to restart the app regularly, or at the least monitor it
for crashes. ServerDoc (www.serverdoc.com) works very well for that, and
I've used it for years. It's designed for game servers, but works well with
VFP. If the VFP app crashes (which it will do sooner or later), ServerDoc
very happily restarts it. It can also restart the app on a regular basis,
like every 24 hours or whatever interval works for you.
The problem that I've had with restarters (I wrote my own because I
didn't know about this program) is that the failure mode such as C5,
always leave the main window open so it looks like the application is
still running. In reality, it is waiting for a user to click the ok
button before it finishes failing. Does anyone have a solution for
that problem? Thanks.
JayB
2010-06-30 13:39:27 UTC
Permalink
if something is always running, then the clock tics should be ticking.
this can be measured from an api from the program watching, and if it
fails to increase in the pre determined amount of time, just end the
process and fire up another one.

also, i believe that the window prompting for user attention should also
have its separate windows handle and could also be found thru the
appropriate API. windows could be sent a message to close it.

jay
Post by Jeff Grippe
Post by Zootal
You need something to restart the app regularly, or at the least monitor it
for crashes. ServerDoc (www.serverdoc.com) works very well for that, and
I've used it for years. It's designed for game servers, but works well with
VFP. If the VFP app crashes (which it will do sooner or later), ServerDoc
very happily restarts it. It can also restart the app on a regular basis,
like every 24 hours or whatever interval works for you.
The problem that I've had with restarters (I wrote my own because I
didn't know about this program) is that the failure mode such as C5,
always leave the main window open so it looks like the application is
still running. In reality, it is waiting for a user to click the ok
button before it finishes failing. Does anyone have a solution for
that problem? Thanks.
Gianni Turri
2010-06-28 08:03:28 UTC
Permalink
Try sys(1104).

I have used it years ago with VFP7 to avoid memory leak in a maintenance procedure that otherwise was unable to complete.

The procedure was working with very big tables, near 2 GB limit, and using a counter it made a call to sys(1104) every 10000 record processed and at the end of every long procedure.

Gianni
Post by Lew
VFP9/sp2 on W2003/sp2 server
I just modified an existing app to run indefinitely. It's a pole/parse/
report thingy, so its memory use is large when it finds and digests
large files, but small when quiet & not poling. I know there used to
be memory issues between earlier versions of VFP used for this kind of
app and the Windows servers leading one or both to eventually fail.
Thing is, I haven't kept up on these issues.
Are the gremlins still out there? What should I be watching out for?
Dan Freeman
2010-06-28 16:57:16 UTC
Permalink
Post by Gianni Turri
Try sys(1104).
I have used it years ago with VFP7 to avoid memory leak in a maintenance
procedure that otherwise was unable to complete.
The procedure was working with very big tables, near 2 GB limit, and using a
counter it made a call to sys(1104) every 10000 record processed and at the
end of every long procedure.
Gianni
Post by Lew
VFP9/sp2 on W2003/sp2 server
I just modified an existing app to run indefinitely. It's a pole/parse/
report thingy, so its memory use is large when it finds and digests
large files, but small when quiet & not poling. I know there used to
be memory issues between earlier versions of VFP used for this kind of
app and the Windows servers leading one or both to eventually fail.
Thing is, I haven't kept up on these issues.
Are the gremlins still out there? What should I be watching out for?
There was also a bug in buffering that only affected long-running
processes. (The cause of my only call to tech support over the last 10
years.) At the end of every iteration, just turn buffering off and then
back on.

This one was fixed in VFP8, SP2, but you never know when it could
manifest itself under conditions other than where we turned it up.

Dan
Lew
2010-06-28 18:35:19 UTC
Permalink
Post by Gianni Turri
Try sys(1104).
The syntax for sys(1104) seems to demand a work area. Nothing's open
at the beginning of each iteration, so what workarea would I use?
Also, I'm not using table buffering.
Gianni Turri
2010-06-28 22:09:23 UTC
Permalink
Post by Lew
Post by Gianni Turri
Try sys(1104).
The syntax for sys(1104) seems to demand a work area. Nothing's open
at the beginning of each iteration, so what workarea would I use?
Also, I'm not using table buffering.
From VFP help:

Purges memory cached by programs and data, and clears and refreshes buffers for open tables.

The parameter is optional.

I forgot to tell you to simply give it a try ...

Put a call to it in this way:

sys(1104)

after completion of your main procedure.

Gianni
Loading...