Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Does VFP6 Cause Resource Leaks?
Message
From
24/02/2001 10:31:03
 
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
00478422
Message ID:
00479209
Views:
39
I'm new here today. Hope you find this of some use.

I saw a brilliant piece of code which I copy below

******* cut *******
* from news group microsoft\public\vfp\forms
* We have a complex foxpro app that would, after several hours of use, start
* behaving erratically. After a LOT of research we discovered the problem to
* be related to using certain activex controls that were not releasing
* resources. Our problems disappear under Win2k. The following code is used
* to detect when Win9x resources dip below a certain amount, when they do we
* first message, then forc the user to exit and re-enter the application which
* frees up used resources.
set library to home()+ 'foxtools.fll' additive
return GetSystemResources()
************************************************
* Begin Code Segment
************************************************
FUNCTION GetSystemResources
LOCAL nGetSysRes,nRetSys,nRetGdi,nRetUser
lcOs=OS()
IF "NT"$lcOS OR "5.00"$lcOS
return 101
ENDIF
If !"FOXTOOLS" $ UPPER(SET("LIBRARY"))
wait window "Foxtools not loaded" timeout 1
return 101
ENDIF
nGetSysRes = RegFn("GetFreeSystemResources", "I","I","USER.EXE")
IF vartype(nGetSysRes)<>"N"
nGetSysRes=-1
EndIf
IF nGetSysRes > -1
nRetSys = CallFn(nGetSysRes, 0) &&system resources
nRetGdi = CallFn(nGetSysRes, 1) &&gdi resources
nRetUser = CallFn(nGetSysRes, 2) &&user resources
ELSE
Store 101 to nRetSys,nRetGdi,nRetUser
ENDIF
wait window ;
[Sys resource ] + alltr( str(nRetSys))+chr(13)+ ;
[Gdi resource ] + alltr( str(nRetGdi))+chr(13)+ ;
[User resource ] + alltr( str(nretUser))NOWAIT
RETURN MIN(nRetSys,nRetGdi,nRetUser)
******************************************************
* End Code Segment
******************************************************
* The above code segment returns the smallest of the available resources under
* Win9x which are divided into System, GDI, and User resources(require foxtool
* library to be loaded). You cannot rely on standard foxpro built in
* functions for this info.
*
*
* I understand that this only allows you to detect the problem and does not
* solve it. Try the following:
*
* 1. Run system on other hardware (dell, compaq, etc..) with standard vga
* drivers and see if it still bombs. If it doesn't then you've isolated the
* problem to a hardware driver issue (video or other)
*
* 2. Use the above function to try determine which process is depleting system
* resources ( I am assuming your problem is a memory leak type issue).
*
* 3. Try modifying your long running code to use different techniques. EG if
* you are creating large number of text files use different commands and see
* if they produce better results: strtofile(), fopen/fputs, copy to file sdf,
* are all different ways to create a text file. If you are processing SELECT
* stmts into a table located on the share, try putting them local and then
* copy them up upon completion. Make sure all your SELECT statements use the
* NOFILTER clause. If you are using a REPORT form sent to a file, try
* changing to a generic printer driver (or at least a different one) to see if
* this helps.
*
* 4. Try creating all of your files locally, then upon finish, copy the files
* to the share either with "copy file" or by shelling out and running os
* command.
*
* Good luck man...I feel your pain.
*
* Jimbo
*
*
* "Tom Price" wrote in message
* news:3A9580AF.AF480EB9@ncmail.net...
* > I have a long running program that is creating problems on Win95 OSR2
* > boxes. It reads a number of Visual Foxpro tables and generates large
* > numbers of files on a network share. It is not unusual for the program
* > to run 15 minutes to several hours.
* >
* > Sometimes it hangs system. In this case, keyboard hangs, screen saver
* > stops, and you must power the system off and back on again.
* >
* > Other times, the screen gets corrupted, for example, one row of pixels
* > in the title bar turns green or you get a gray line through the task
* > bar. Again you must power off.
* >
* > Other times, other programs crash or you get Win95 BSODs "Fatal
* > exception 0D in vxd vmm at 0028:C00090D0. Might as well power off then
* > too because Explorer is going to crash or lock up.
* >
* > Other times, system spontaneously reboots.
* >
* > I installed Norton's CrashGuard. Occasionally, it catches it but the
* > situation is never recoverable. Many more times, system crashes with no
* > intervention message.
* >
* > The Windows resource meter showed plenty of resources but Norton System
* > Doctor showed user resources were being depleted. I added a "wait
* > sys(1016) window nowait" to parts of the code and it showed
* > progressively higher numbers but they did not seem to increase at a
* > uniform rate; it would stay more or less constant for a long time then
* > jump.
* >
* > I had two third-party OLE controls on the form. I took them off. That
* > decreased the user resources in use and seemed to prolong the crash. But
* > I can't leave these off permanently.
* >
* > 16-bit applications running on the machine at the same time seem to make
* > the problem worse.
* >
* > I ran the system through the M$ windows update web site and it is
* > current on maintenance. I updated the virtual redirector and implemented
* > the DiscardCacheOnOpen as described in Q148367. No effect.
* >
* > The same code ran for hours on a Win2K workstation with no failures.
* >
* > This is a substantial program and I've commented out large portions of
* > it to attempt to isolate the problem. But I feel like I'm shooting in
* > the dark. Are these crashes consistent with a resource problem? How can
* > I troubleshoot this kind of problem? Are there specific kinds of things
* > that would cause it so as to focus my efforts?
* >
* > My project is late and the alligators are chomping at my tail. Any and
* > all help is most appreciated.
* >
* > TIA
* >
******* cut *******
regards Alan
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform