Is it safe to delete the log.txt file periodically?

Case number:671071-997610
Topic:Game: Other
Opened by:jeff101
Status:Open
Type:Question
Opened on:Friday, May 2, 2014 - 12:59
Last modified:Thursday, July 7, 2016 - 02:21

Hi You All,

I have noticed that the longer it has been since I updated a particular Foldit client, the larger this client's log.txt file becomes. log.txt only seems to shrink when I update a Foldit client. I often wonder if some of my Foldit crashes are caused by log.txt simply becoming too large. Also, does a large log.txt file actually slow down Foldit?

Because of these things, I am considering deleting the log.txt file periodically. Is this a safe thing to do? Is it best to do this between Recipes? When is it safest to delete the log.txt file? Perhaps I could just move log.txt to logold.txt each time, then I would have a backup of the most recent activity in log.txt at least. Please advise.

Thanks,
Jeff

(Fri, 05/02/2014 - 12:59  |  16 comments)


gitwut's picture
User offline. Last seen 1 year 13 weeks ago. Offline
Joined: 05/18/2012
Groups: Contenders

In general, it is considered bad practice to delete/modify/rename a file when it is in use. I believe that the file is in use as long as any Foldit client (assuming clients run from the same folder) is open. So I wouldn't recommend changing it in any way unless all of your clients sharing the log.txt file are closed. However, when no clients are running the next opened client will overwrite the file anyhow.

These are generalities, though, so it it possible to ignore everything above and you "might" not encounter any problems depending on how well the application is designed to handled these possibilities.

Susume's picture
User offline. Last seen 3 hours 11 min ago. Offline
Joined: 10/02/2011

I believe a new log.txt is created every time you open a client, overwriting the previous log.txt even though your other clients are still running. From then on all the clients will write to the new one. So it should be possible to reduce the size just by opening a client.

That said, there is currently a bug causing even a new client to write megabytes of nulls to the log.txt, bloating it unnecessarily.

Joined: 04/20/2012
Groups: Go Science

If it isn't safe for players to delete the log.txt file, maybe Foldit should periodically and automatically close it and rename it like log1.txt, then start a new log.txt file. If log1.txt already exists, instead rename log.txt like log2.txt or log3.txt or whatever number would come next. Then if players wanted to, they could safely delete the log1.txt log2.txt log3.txt etc files. Also, when a client restarts and the old log.txt gets overwritten, Foldit could automatically delete the old log1.txt log2.txt log3.txt etc files as well.

Joined: 04/20/2012
Groups: Go Science

Would anyone from the Foldit team care to comment on the above? Lately, it seems like clients on my Windows laptop respond more slowly the longer they run. Once I restart them, they respond more quickly. Is it safe to remove a log.txt file while its client is running? Will this make the client more responsive?

Thanks!
Jeff

LociOiling's picture
User offline. Last seen 25 min 30 sec ago. Offline
Joined: 12/27/2012
Groups: Beta Folders

A few thoughts on this topic:

1. I run each client from a separate directory. This way log.txt gets overwritten each time you restart a client. Also, the messages in log.txt apply only to a particular client, so they may be more useful for debugging. Separate directories also makes sure your scriptlog files contain messages from only one recipe.

2. On Windows, you can simply copy a Foldit directory. If your client is installed in c:\foldit, you can copy that and create c:\foldit2, c:\foldit3, and so on. Add some shortcuts and away you go.

3. Foldit leaves a lot of *.ir_solution and other files (such as scriptlogs) laying about. I do a periodic "spring cleaning", making new client folders from a fresh install, and keeping only options.txt, all.macro, and foldit.ico from the the old folders.

4. I have a custom foldit.ico for each folder, just the regular Foldit icon with a number. This helps me keep track of which client is which. I used a free icon editor "IcoFX Portable" to create the custom icons.

5. As BletchleyPark has discovered, Foldit has a pretty major handle leak. This is one more good reason to close and reopen clients often. If you run EDRW for a couple of days, you may find you client has 200,000 open handles. Each handle by itself is insignificant, but having 200,000 of them won't speed things up.

Joined: 09/24/2012
Groups: Go Science

But I suppose that this way we cannot easily open a solution from one directory to the other without first "sharing" to ourselves?

Joined: 09/24/2012
Groups: Go Science

Thanks Loci for the tip.
But I suppose that this way we cannot easily open a solution from one directory to the other without first "sharing" to ourselves?

Joined: 04/20/2012
Groups: Go Science

Thanks Loci. In the Feedback about the handle leak cited in 5 above, BP posts an image of the Windows Task Manager showing a column for Handles (http://fold.it/portal/files/open%20handles%20bug.png). I will start monitoring this column.

Joined: 04/20/2012
Groups: Go Science

It seems like a Foldit.exe client will behave alright on a Windows machine until its Handles column in the Windows Task Manager approaches 200,000. When the number of Handles grows this large, the Foldit GUI becomes very unresponsive, at times giving the spinning disk or "Not Responding" message. Also, un-minimizing a client with a large number of Handles can take a long time. It also seems that killing clients with the most Handles improves the overall performance of a computer, letting the computer's other clients operate at their normal speed again.

I think some Recipes make the Handles column grow more quickly than others. Monitoring this growth rate for different Recipes could give clues about what Foldit functions/tools/commands cause the Handle Leak.

Joined: 04/20/2012
Groups: Go Science

See https://fold.it/portal/node/2002316 for more details about Foldit's Handle Leak.

Joined: 04/20/2012
Groups: Go Science
Joined: 05/19/2009
Groups: Contenders

What I did is: start a client, stop it, then make the log.txt file read-only. This keeps the file at a few kilobytes and has no negative impact on gameplay. I used to have gigabytes of logfiles. No more :)

Joined: 05/19/2009
Groups: Contenders

hmm, come to think of it, that may influence the open handle issue.... Thanks for mentioning that Loci !

Joined: 04/20/2012
Groups: Go Science

Numerical Recipes in C, Second Edition (1992)
https://www.nrbook.com/a/bookcpdf.php
https://www2.units.it/ipl/students_area/imm2/files/Numerical_Recipes.pdf

gave the following code in a file called nrutil.c:

double *dvector(nl,nh)
int nl,nh;
{
	double *v;

	v=(double *)calloc((unsigned) (nh-nl+1),sizeof(double));
	if (!v) nrerror("allocation failure in dvector()");
	return v-nl;
}

void free_dvector(v,nl,nh)
double *v;
int nl,nh;
{
	free((char*) (v+nl));
}

void nrerror(error_text)
char error_text[];
{
	void exit();

	fprintf(stderr,"Numerical Recipes run-time error...\n");
	fprintf(stderr,"%s\n",error_text);
	fprintf(stderr,"...now exiting to system...\n");
	exit(1);
}

A call to dvector would dynamically allocate
(see https://en.wikipedia.org/wiki/C_dynamic_memory_allocation)
an array of doubles. Each call to dvector had to eventually be
followed by a call to free_dvector to free the memory used by
dvector. nrerror was used to print error messages.

If you didn't include the right number of free_dvector calls in
a program, your program would gradually use more and more memory,
slowing down and eventually crashing in the process.

I wonder if something like this is occurring in Foldit, either
with Foldit's underlying code or in a similar manner in certain
LUA Recipes.

Joined: 04/20/2012
Groups: Go Science

Numerical Recipes in C, Second Edition (1992)
http://www.nrbook.com/a/bookcpdf.php
https://www2.units.it/ipl/students_area/imm2/files/Numerical_Recipes.pdf

also gives the following functions in nrutil.c:

double **dmatrix(nrl,nrh,ncl,nch)
int nrl,nrh,ncl,nch;
{
	int i;
	double **m;

	m=(double **) calloc((unsigned) (nrh-nrl+1),sizeof(double*));
	if (!m) nrerror("allocation failure 1 in dmatrix()");
	m -= nrl;

	for(i=nrl;i<=nrh;i++) {
		m[i]=(double *) calloc((unsigned) (nch-ncl+1),sizeof(double));
		if (!m[i]) nrerror("allocation failure 2 in dmatrix()");
		m[i] -= ncl;
	}
	return m;
}

void free_dmatrix(m,nrl,nrh,ncl,nch)
double **m;
int nrl,nrh,ncl,nch;
{
	int i;

	for(i=nrh;i>=nrl;i--) free((char*) (m[i]+ncl));
	free((char*) (m+nrl));
}

Here, every call to dmatrix dynamically
allocates memory for a 2-dimensional array of
doubles, and eventually every call to dmatrix must
be followed by a call to free_dmatrix to free
the memory used by dmatrix. If the right number
of free_dmatrix calls is not used, the computer's
memory gradually fills, and the calling program
gradually slows down until it crashes.

Susume's picture
User offline. Last seen 3 hours 11 min ago. Offline
Joined: 10/02/2011

foldit does not seem to have a memory leak. Even clients that have been running for days stay about 600-800 MB (depending on protein length) in memory. I don't think having a large log.txt increases foldit's size in memory. I doubt that having a large log.txt slows down foldit's running either - I assume foldit is not scanning the file, just appending to it, which is quick. Assuming you have room on your hard drive, I very much doubt a large log.txt could crash the game.

The easiest way to deal with a large log.txt that is bothering you is to periodically restart a client between recipes, and always between puzzles.

Sitemap

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons