Curious dfGUI problem

[rsbriggs]

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....

[rsbriggs]

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....

[Darkness Productions]

Try (as everyone else suggests) running the client without dfGUI, see if that helps you at all...

[rsbriggs]

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...

[bwkaz]

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)?

[Angus]

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.

[rsbriggs]

I have the same results as you on a 2x HT box running 4 clients - I haven't seen as much as a single error message in the log files (except when the server was down), running under win2k. Nary a glitch - they just keep going and going [pic of pink energizer bunny would be nice here]

However on the 4x HT box, it's rare that I can keep any of the clients running for hours in a row.... (But I've now got the additional problem that both my available terminal server connections into the box have crashed, so I can't do much of anything until I can physically get to the box tomorrow at work. That makes me think that Win2K server on the box is having troubles...)

I'm not the administrator of the box - I'm, um, er, just running some CPU and memory testing applications on it after hours when it isn't otherwise in use. 8 testing applications, one for each real and virtual CPU - just to max the CPU usage and exercise memory some - I don't know why the test apps are called "foldtrajlite" exactly - something to do with some technical term regarding the way they test ram, maybe?

(I may have to quit using the box - DF appears to be adversely affecting it....)

I'm going to attempt to re-boot it early tomorrow morning - I'll be able to play more with it over the weekend, if I can get it settled down tomorrow.

[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.

[Welnic]

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.

[IronBits]

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...

[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.

[MTP]

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

[Digital Parasite]

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.