-
Not here
Curious dfGUI problem
Starting to run into some strange problems with dfGUI. Lots of my clients are stopping on a quad-HT-Xeon box with RLEUnpack length incorrect. Once that happens, it is impossible to close dfGUI - any attempt to do so gives me an "EXTERNAL EXCEPTION C0000006" message box. Can't close the prog, have to kill the process.
I'm going to have to re-name the dfGUIs or something - I can't tell which of the 8 dfGUI processes to kill....
FreeDC Mercenary
-
Not here
UGH. You probably have no idea what a can of worms it opens when you try to rename dfGUI to dfGUI7 and foldtrajlite.exe to foldtrajlite7.exe.
Doesn't work, dfGUI seems to re-create foldit.bat each time it starts, and builds the name foldtrajlite.exe into the batch file. Also, it doesn't much like navigating to foldtrajlite7.exe when looking for the same name without the 7, even if it is configured that way.....
All 8 of my clients on the Xeon box are dead - none will run due to RLE unpack errors.
The 4 gigs of memory on that box is both registered and ECC, and has never had any problems....
FreeDC Mercenary
-
Stats God in Training
Try (as everyone else suggests) running the client without dfGUI, see if that helps you at all...
-
Not here
I'm not certain that this is a dfGUI problem. I'm running a similar setup on a 4x processor box, and I'm not seeing the same troubles - no apparent memory problems - nor am I seeing any sort of problems on any of my single boxen.
The only problem that dfGUI seems to have is: if the client aborts in a certain way, dfGUI can't be closed - you get that C0000008 external exception error when you attempt to close it.
Hmm - one other observation - after manually killing the dfGUI process, that particular instance of dfGUI seems to have lost its configuration information. The path seems to be reset to .\ , the CPU name is reset to the default, and the "use extra ram" box isn't checked anymore....
IMHO dfGUI doesn't seem to be the root cause of the client underneath aborting. Seems more like a problem with hyperthreading. Or, maybe the 4 gigs of memory on that box really IS bad...
Last edited by rsbriggs; 06-26-2003 at 10:11 AM.
FreeDC Mercenary
-
Senior Member
As someone else posted, that exception number seems to have something to do with either swap, or RAM.
Does it happen if you run the client without -rt?
Does it happen after a reboot? (maybe it's just Windows' panties getting in a bunch... God knows it happens enough at work, and those are 2K boxes )
Where's your swap file? If it's a file on your C drive, which is probably still the default, see if you can limit the size. I remember Win98 had an option where it would automatically grow the swap file as needed, but I'm not sure how well it worked (I always turned that off and went with a fixed-size swap). If it was broken then, and it's still broken now, ... you can see where I'm going with that, I think.
Or, maybe it's some type of hard drive issue? Tried running scandisk in "full" mode or whatever it's called now (where it tests each sector to make sure they're not bad)?
-
Ancient Haggis Hound
The whole thing sounds odd....
I'm running 4 clients on each of my dual Xeon HT boxes, each box has 2GB of RAM, and running W2K Advanced Server.
I start the clients using dfGUI, and use it to configure them, then shut down dfGUI. I use DCMonitor to keep track of wht's going on.
I haven't had a single client crash on any of the 5 boxes (20 clients). I'm running them with -qt -rt -i f , and the only problem I see is the memory leak causing RAM usage to constantly increase from the 89MB at startup.
Edit: I have never even attempted to run this as a service. These run in 'hidden' mode using the dfGUI option to hide the client.
Last edited by Angus; 06-26-2003 at 03:18 PM.
-
-
Need a DC Project to run
I have a random issue as well. Sometimes when I start the dfgui it says the "client appears to be running" when it fact it is not.
If I shut it down and restart it turns it on the client like it is supposed to and work fines fine from there.
-
Senior Member
Originally posted by MTP
I have a random issue as well. Sometimes when I start the dfgui it says the "client appears to be running" when it fact it is not.
If I shut it down and restart it turns it on the client like it is supposed to and work fines fine from there.
I think that dfgui mainly checks for the progress.txt file to see if it is running and how it is doing. That is never there if the client shuts down correctly. But if the client crashes it can still be there and so dfgui thinks it is still running.
-
Target Butt
It only deals with the .lock file. It is really mis-leading and it should be changed to say, lock file present.
I always use task manager to see if the client is working. If not, I click stop, so that DFGui will remove the .lock file, then I click start, watch with task manager to make sure it does start. If not, I check the error.log file to see what it has to say...
-
Not here
( maybe the author could weigh in here ? )
My observation is that if the client crashes, it leaves the foldtrajlite.lock file. dfGUI seems to think the client is running if this file exists (even if the client isn't running).
When you tell dfGUI to stop the client, it removes this file, and (now correctly) believes the client has stopped. When you re-start the client, it re-creates the .lock file, dfGUI (correctly) thinks the client is running, and everything is OK once again.
FreeDC Mercenary
-
Need a DC Project to run
It seems the dfclient does not release the cpu as well as other DCprojects due, or maybe it has something to do with the HT ability of the cpu.
If I do not close the dfgui and stop the client, it has caused a few random reboots when I am in the middle of other system loading apps. However if I stop the cleint I can run those apps froever it seems and have zer issues.
I always stop the client using the dfgui, so those issues I mention must be from the system reboots I experienced.
Thanks
-
Cryptomaniac
Originally posted by rsbriggs
( maybe the author could weigh in here ? )
My observation is that if the client crashes, it leaves the foldtrajlite.lock file. dfGUI seems to think the client is running if this file exists (even if the client isn't running).
When you tell dfGUI to stop the client, it removes this file, and (now correctly) believes the client has stopped. When you re-start the client, it re-creates the .lock file, dfGUI (correctly) thinks the client is running, and everything is OK once again.
Hey rsbriggs,
I usually don't have time to monitor all the DF Team forums to see if anyone happens to be posting about problems with dfGUI so I just happened to see this because I am announcing v3.1. The best way to get my attention is to e-mail me if you have a problem.
You are correct, at the moment dfGUI just looks for the .lock file to determine if the client is "running" or not. I could change the wording from "Appears to be running" to something stronger like "Foldtrajlite.lock found, Client may be running" if people really want me to.
The only code I know of to look in the process list to see if "foldtrajlite" is actually running doesn't work with NT4 so that would stop anyone who has NT from using dfGUI on their system.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules