Forum archive 2000-2006

Donald Behan - Problem with displayMacros.pl

Donald Behan - Problem with displayMacros.pl

by Arnold Pizer -
Number of replies: 0
inactiveTopicProblem with displayMacros.pl topic started 9/4/2001; 1:13:08 PM
last post 10/20/2001; 8:23:25 AM
userDonald Behan - Problem with displayMacros.pl  blueArrow
9/4/2001; 1:13:08 PM (reads: 2354, responses: 7)
Has anyone had a problem with displayMacros.pl? While editing problems the system displays an error message "can't rename temporary problem directory ... at displayMacros.pl line 478" From that point on the problem can no longer be displayed, even when I copy over the file within SSH. Any suggestions?

<| Post or View Comments |>


userBill Ziemer - Re: Problem with displayMacros.pl  blueArrow
9/4/2001; 1:18:04 PM (reads: 2656, responses: 0)
I still have the same problem, even in precreating! Arnie addressed it in an earlier post. I have copied it here for convenience.

 

Typeset mode uses latex2html which is a very slow process and is also subject to random errors which may cause a student's problem to be unviewable in typeset mode. Depending on the speed of your server and the complexity of the problem, it may take 6 seconds per student per problem to create the problem the first time it is created. For this reason we cache the problem images in typeset mode (and suggest you precreate them) which speeds things up tremendously but can cause other complications. What follows is a pretty detailed explaination of what is going on and some suggestions regarding the use of typeset mode.

If a student can not view a problem, tell them to switch to "formatted text" mode and they will be able to view the problem (they can also use the hard copy). Here is how things work and how to fix them so the student can use typeset mode.

When a student views a problem in typeset mode, webwork looks for a directory where the images should be (I'll tell you where below). If the directory exists and is more recent then the date of the problem .pg file, webwork uses the images in that directory. Otherwise it (re)creates the directory. Thus if somehow bad images are created, that is all a student will see. To fix this, you just have to remove the bad directory. These directories are under l2h in the tmp directory. By default this is e.g.

.../mth161/html/tmp/l2h

but we suggest you put this in a separate file system e.g /home/htdocs/tmp and then you would have /home/htdocs/tmp/mth161/l2h

under l2h/ you will see e.g

drwxrwx--- 4 wwhttpd MTH161 512 Dec 13 21:56 1-40080/

drwxrwx--- 113 wwhttpd MTH161 3072 Dec 16 12:44 set0/

drwxrwx--- 1102 wwhttpd MTH161 21504 Dec 16 14:00 set1/

drwxrwx--- 4153 wwhttpd MTH161 75264 Dec 15 15:15 set10/

drwxrwx--- 5079 wwhttpd MTH161 93696 Dec 16 15:08 set11/

drwxrwx--- 1879 wwhttpd MTH161 41984 Dec 16 13:55 set12/

drwxrwx--- 4127 wwhttpd MTH161 88064 Dec 15 14:51 set13/

drwxrwx--- 4122 apizer MTH161 87552 Dec 15 17:13 set14/

drwxrwx--- 1851 apizer MTH161 40960 Dec 16 05:17 set15/

drwxrwx--- 7048 apizer MTH161 134144 Dec 22 20:05 set2/

drwxrwx--- 5579 wwhttpd MTH161 104448 Nov 22 15:19 set3/

All you should see are set0, set1, etc. The 1-40080/ is a bad directory.

Under a set you will set e.g. .../l2h/set2/3-45678

This is the directory for prob 3 from set2 for psvn number 45678. If the student with psvn 45678 had trouble viewing prob 3 in set2, this is the directory your would remove. The directories are created under l2h and then at the last stage moved under the proper set so if they don't get moved, they are bad which is what happened in the case of the directory 1-40080/ above.

If you remove a student's directory you can check that things are OK by viewing the student's problem. From the prof page (item 3) go to this student's entry and view the problem in typeset mode. This will run latex2html and rebuild the typeset html page.

Even if the directory gets moved to the proper location (e.g. under .../l2h/set2/), there may be bad images. Bad images seem to be a random problem which is related to the speed and load on your server. If you have a fast server, you will almost never see this problem. If you have a slow heavily loaded server, you will see it a lot. Preceateing the latex2html images is a very good way to avoid this problem. Otherwise at busy times many students may be viewing problems for the first time which causes latex2html to be called which puts a high load on the server which makes these random errors more likely.

How can you recognize when and where these random errors have occured (other than receiving an email from a student)? If a directory e.g. set2/3-12345/ contains any files of the type *.old or *.css or a subdirectory named l2h*, it is bad and should be removed. Maybe we should write a script which searches for and removes such directories, but we haven't found that necessary.

<| Post or View Comments |>


userZbigniew Fiedorowicz - Re: Problem with displayMacros.pl  blueArrow
9/4/2001; 7:29:48 PM (reads: 2645, responses: 0)
I am responding to Donald's message. I have had similar error messages. In each case the trouble was caused by bugs in the problem's PG code, eg. there was a mismatch in the number of answer boxes and the number of answer evaluators. Try viewing the problem in formatted text mode or plain text mode and clicking on the Submit button. You might get a more sensible error message which might help you pinpoint things better. Also clicking on "Get Hard Copy" and eyeballing the layout of the problem might furnish some clues.

Zig Fiedorowicz

<| Post or View Comments |>


userZbigniew Fiedorowicz - Re: Problem with displayMacros.pl  blueArrow
9/4/2001; 7:45:57 PM (reads: 2630, responses: 0)
This is in response to Bill's message. You can get seemingly random sporadic errors in l2hPrecreate if there is some bug in your problem code which results, eg. in division by zero for some choice of the random parameters in the problem. Then the l2h image directories for those unlucky students for whom the bug was triggered will be bad.

After locating the bad l2h directories, try viewing those students' versions of the problem in formatted text mode. You will probably get a more clueful error message.

Zig Fiedorowicz

<| Post or View Comments |>


userDonald Behan - Re: Problem with displayMacros.pl  blueArrow
9/5/2001; 7:45:51 PM (reads: 2701, responses: 1)
This is not related to syntax errors in the problems, as it is happening to numerous problems that had worked previously. Also, when I try to do precreate, it is spitting out errors at a rate of five or ten per minute. I replaced a particularly troublesome question with a blank question that just has the macro setup. This had always shown in typeset mode before. I am not aware of any latex being used in the blank problem. When I tried to view it in typeset mode, I got the same error message. Is it possible that there is some other place besides the bad directory (which I erased) where the problem is marked as being bad, regardless of the current content?

A further problem is that I tried to run a problem with a solution, and got a similar error, but I cannot erase the related directory, because I don't have permission to erase about 10 files in the bad directory.

<| Post or View Comments |>


userBill Ziemer - Re: Problem with displayMacros.pl  blueArrow
9/10/2001; 1:25:09 PM (reads: 3107, responses: 0)
The problem we had is with too large a set. The error message was "can not rename ...". But there were none of files that indicate a bad precreate. Turns out, the ext2 filesystem in Linux can only address 32000 files (directory uses a table with 16 bit entries). We had 74 problems with 525 students = 39000 or so subdirectories of <WebWork course>/html/tmp/l2h/set1. Splitting the homework into pieces fixed the problem.

<| Post or View Comments |>


userDonald Behan - Re: Problem with displayMacros.pl  blueArrow
10/18/2001; 4:15:00 PM (reads: 2590, responses: 0)
I am still struggling with this error message. There seems to be some file or component that I am not removing when I follow the suggestions above and remove the numbered files in the l2h directory, so that the problem is unable to be corrected. In a particular example the only latex portion is one simple symbol, and the problem can't be precreated even when the system is 100% idle.

<| Post or View Comments |>


userArnold K. Pizer - Re: Problem with displayMacros.pl  blueArrow
10/20/2001; 8:23:25 AM (reads: 2625, responses: 0)
Hi Don,

If you look at the apache error_log you will see:

perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in free(): warning: recursive call. perl in malloc(): warning: recursive call. Out of memory!

Almost certainly one of your problems contains an infinite loop.

Also your version of l2hPrecreateSet (on webwork2) is a pre release version which forks off child processes, but continues on even if a child process returns an error code. We will upgrade l2hPrecreateSet on webwork2 shortly so the main process will end if a child dies.

If you do not know which of your problems is a fault, view them one at a time on the web. When viewing a problem over the web, there is a 60 second timeout limit so you will either hit that limit or see some other error message.

<| Post or View Comments |>