|
Post by Jos on Feb 14, 2019 8:27:15 GMT 1
Contacted by direct mail.
Jos
|
|
|
Post by johngoebel on Feb 14, 2019 19:38:46 GMT 1
Thank you very much. I downloaded the file and ran it on one of my test systems with very good results: Compiled project 5 times, no errors. Re-indexed large file (409,750 records, 5 tags) 5 times, no errors. Re-index larger file (1,486,900, 3 tags), 5 times, no errors.
I will test it on production system next week John
|
|
|
Post by Jos on Feb 14, 2019 20:03:29 GMT 1
Did you notice any speed improvement? If not, could you start vDos with the log option ("…\vDos.exe" /log), then run some procedure that caused a Page Fault error before, and send me the generated vDos.log file.
Jos
|
|
|
Post by darko on Feb 15, 2019 14:50:15 GMT 1
if you have problems with foxprox and page fault try include following command into your autoexec.txt file or type this into command prompt before running foxprox program:
SET FOXPROX=-SAVEREGS
After that all my problems with "Page fault: directory or table entry not set" disappears. Now I can PACK database od 1,200,000 records without problem, before I can't PACK 600 records without Page fault.
And Jos thank you for your work and great VDOS program
Darko
|
|
|
Post by Jos on Feb 15, 2019 15:38:43 GMT 1
That’s certainly worth trying for those with FoxProX Page Fault errors. Hopefully there will be some feedback on the results.
My conclusion was that the Phap Lap DOS extender gets confused when HMA (the first 64 MB of XMS) is available as in vDos. XMS is properly detected, split into 16 equal chunks, that are claimed, freed and claimed again and the virtual-to-physical address tables correctly setup. But at some moment FoxProX just presents an invalid virtual address causing the "Page fault: directory or table entry not set" exception. It’s however not just a random address, a close look at the virtual-to-physical entries revealed it’s what would have been setup for the next address beyond the XMS limit. So after initializing the virtual-to-physical tables, Phar Lap seemingly adds the HMA to the amount of available XMS memory. The exception occurs randomly because FoxProX is lazy with memory management, reorganizing when it feels like (being idle), or it has to.
Jos
|
|
|
Post by foxpropgmr on Feb 15, 2019 17:39:54 GMT 1
Hi again ...
I DO wish to stress that the 5/30/2018 version is better with regard to the page faults than prior versions and vdosplus. So, Jos, you did something right. Page faults in prior versions were more frequent and reproduceable.
Strangely enough it may be machine specific. It happens to me and another poster. But I have a client with two machines that use vdos and they say they've never seen a page fault.
Maybe a clue?
|
|
|
Post by foxpropgmr on Feb 15, 2019 17:55:38 GMT 1
Just tried the "SET FOXPROX=-SAVEREGS" thing.
Early results look good. I'll post feedback ina couple of weeks.
Walt
|
|
|
Post by Jos on Feb 15, 2019 18:42:09 GMT 1
Well, this reminded me of playing in the past with environment variables to bypass the Page Fault errors. Completely forgot about that, here’s an email message of February 2nd 2016 I found: That FoxProX problem is known, but still not solved despite many intensive attempts to track it down. It appears to be related to the DOS environment, the totaling size of the contents has some critical values where the Phar Lap Extender/FoxProX at some time will address non-initialized directory entries with page mapping.
You probably can make it go away by adding some variable to the DOS environment, the whole (name=value) being at least 16 characters. Or clear the WIN_USERNAME and WIN_VDOS variables if not used. Possibly also precede the command to start your program with a @, 4DOS will then clear the CMDLINE variable.WIN_USERNAME and 4DOS/CMDLINE don’t apply anymore. I’m curious: - What when "SET FOXPROX=-SAVEREGS" is for instance changed to " SET FIXPROX=-SAVEREGS"?
- The client (like many others) that never experienced the Page Fault error has some SET command in autoexec.txt?
Still strange that this would trigger FoxProX/Phar Lap not to produce an invalid virtual memory address. Jos
|
|
jgoebel
Guest
|
Post by jgoebel on Feb 15, 2019 19:24:09 GMT 1
We have the following in autoexec.txt, and get page fault errors. SET PATH=C:\WINDOWS\SYSTEM32\ REM Jos sugessted un-setting WIN_USERNAME WIN_VDOS CMDLINE REM to make make it more stable. SET WIN_USERNAME= SET WIN_VDOS= SET CMDLINE= SET LOW=ON SET foxprocfg=C:\Users\term157\FOXRUN\config\TERM157.FP SET DOS_VERSION=vDos SET user=TERM157 SET IP4_ADDR=192.168.1.96 SET FOXPROX=-SAVEREGS looks very interesting. I couldn't find much about it, members.iinet.net.au/~angus/foxpro/foxfaq4a.html says "SET FOXPROX=-saveregs (This command tells FoxPro to preserve any registers in use and not to overwrite them while running)." I am currently testing something else and don't want to muddy the waters. John
|
|
|
Post by Jos on Feb 15, 2019 20:02:50 GMT 1
I thought the vDos I sent you fixed the Page Fault errors.
The suggestion to un-set WIN_USERNAME, WIN_VDOS and CMDLINE was for if those errors occurred. The moment you add or delete other variables, this changes of course. WIN_USERNAME and CMDLINE aren’t set anymore, so these can be removed from autoexec.txt. If SET FOXPROX=-SAVEREGS brings anything, I’m curious if this is due to this specific setting, or just being 17 characters (…at least 16 characters). Don’t know what to make of "This command tells FoxPro to…". Registers would be CPU registers? How does FoxPro know what are in use (by who/what/when)?
Jos
|
|
jgoebel
Guest
|
Post by jgoebel on Feb 15, 2019 21:15:45 GMT 1
The vDos you sent me didn't cause any page faults on my test system, but that's not conclusive because the page faults happen at (seemingly) random times. I started to use the vDos you sent on a couple of office machines today, that will be a better test. So I can't say the new vDos fixed the problem, but I'm very optimistic. It seems like SET FOXPROX=-SAVEREGS is a known solution to errors on some systems using FoxProx. News to me, I've never seen the problem in DOS or NTVDM . computer-programming-forum.com/2-vfp/4b603f8f7fc3cbc6.htm says, among other things, about set foxprox=-saveregs "the line has the effect of causing a FoxPro application to "save" all of the memory registers that are already in use at the time it is run (apparently so they are not "{*filter*}led" later on)."
|
|
|
Post by darko on Feb 16, 2019 0:31:47 GMT 1
Command SET FOXPROX=-SAVEREGS was used before many years in Nowell Netware environment in pre-Windows times. Using Foxprox in Nowell Netware often has generated PHAR-LAP errors very similar those in VDOS.
|
|
|
Post by Jos on Feb 16, 2019 0:32:08 GMT 1
I don’t think SET FOXPROX=-SAVEREGS will do anything in vDos, besides consuming 17(+1) bytes of the DOS environment. That can then fix eventual Page Faults errors, but only due to the mere change to the DOS environment, not the specific variable name or value.
Searching for SAVEREGS (even AVEREG), not case sensitive, gives only two hits in the FOXHELP.FPT file. The text entry starts with: FOXPROW=-SAVEREGS * Only if Novell Netware ODI drivers are being used. No Novell Netware ODI drivers in (DOS of) vDos, so…
The cure of changing the DOS environment by at least 16(+1) bytes is still mystifying, but for now seemingly the best option to try for all vDos versions (if Page Faults occur, else it could just trigger FoxProX/Phar Lap to cause those).
Jos
|
|
|
Post by Jos on Feb 16, 2019 1:03:11 GMT 1
Mind, the environment size cure could well only be a (hopefully long) delay before a Page Fault occurs. Also not always effective at all, the last years the focus shifted to playing with the amount of available XMS. Though neither always effective. Even not possible anymore, assuming FoxProX Page Faults were fixed, XMS is now a static 10 MB.
The second poster – al - uses a pre-release of the next vDos since December 13 and reported it’s working 100% in his production environment. So, as John, I'm fairly optimistic the Page Faults exceptions will be finally fixed.
Jos
|
|
jgoebel
Guest
|
Post by jgoebel on Feb 22, 2019 18:15:10 GMT 1
Jos, After using the vDos version you sent me for 3 days I can report NO page faults with FoxProX. That's not a long test so I can't say it's cured, but I am extremely optimistic. Thanks for all your hard work. John
|
|