This semester I decided to give my first try to using a gateway exam. Things seemed to go well until I tried to add a new student after the closing date of the exam. Although I changed the new student's dates, there were problems in her taking it. The error message she got is received is below. To try to see what was happening, I made a new test and assigned it only to myself. Although the test appeared, when I tried to score it, I got a similar message. Have I missed a setting? Again, this trouble was not manifested on the first exam which about 20 students were able to complete with no trouble.
Thanks for any clue. - I am using version 2.2.
Bayne
---------------------
Error messages
"assignSetVersionToUser" is not exported by the WeBWorK::ContentGenerator::Instructor module
Can't continue after import errors at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 39
BEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 39.
Compilation failed in require at (eval 3801) line 1.
Call stack
The information below can help locate the source of the problem.
* in WeBWorK::Utils::runtime_use called at line 329 of /opt/webwork/webwork2/lib/WeBWorK.pm
Hi Richard,
This seems odd. Let me check to make sure that I understand what you did. My understanding is that you created a course, created or imported students from a classlist file, and created or imported the gateway test that was then assigned to all students.
This worked for all of the students you originally created. Then you added a new student to the course, assigned the test to that student, changed that student's open/due dates for the gateway, and when the student tried to take the test the error you indicate was returned.
In your test case, you report
I'm confused by the error, because it's pointing to a part of the code that shouldn't in any way notice how the test was assigned.
Thanks,
Gavin
This seems odd. Let me check to make sure that I understand what you did. My understanding is that you created a course, created or imported students from a classlist file, and created or imported the gateway test that was then assigned to all students.
This worked for all of the students you originally created. Then you added a new student to the course, assigned the test to that student, changed that student's open/due dates for the gateway, and when the student tried to take the test the error you indicate was returned.
In your test case, you report
I made a new test and assigned it only to myself. Although the test appeared, when I tried to score it, I got a similar message.
Does this mean that you were able to take the test, and it was only when you clicked "Grade Test" that you got the error?I'm confused by the error, because it's pointing to a part of the code that shouldn't in any way notice how the test was assigned.
Thanks,
Gavin
Gavin,
Your understanding is correct. I made the quiz for a course that I had already set up, tested the quiz myself and then had the students take it. When the new student enrolled, I added her to the classlist and assigned the quiz to her. She reported having trouble with it, so I removed her from the class list and reentered her, assigning the quiz again. She reported that she was able to see and take the test but when trying to submit received the error message.
I subsequently made a new quiz, copying the questions from the original, assigned it only to myself and was able to see and take it. But when I clicked the 'grade test' button also received the error. Of course, there was no score recorded for the quiz.
I know the instructions mention something about permissions to see the results that may be included in the global conf file, but I did nothing differently from the first quiz.
Bayne
Your understanding is correct. I made the quiz for a course that I had already set up, tested the quiz myself and then had the students take it. When the new student enrolled, I added her to the classlist and assigned the quiz to her. She reported having trouble with it, so I removed her from the class list and reentered her, assigning the quiz again. She reported that she was able to see and take the test but when trying to submit received the error message.
I subsequently made a new quiz, copying the questions from the original, assigned it only to myself and was able to see and take it. But when I clicked the 'grade test' button also received the error. Of course, there was no score recorded for the quiz.
I know the instructions mention something about permissions to see the results that may be included in the global conf file, but I did nothing differently from the first quiz.
Bayne
Hi again,
This is very odd. I don't think the permissions have anything to do with this. The error message is a Perl error, not a permissions error that is getting caught by WeBWorK.
The error message "'assignSetVersionToUser' is not exported by the WeBWorK::ContentGenerator::Instructor module" is a Perl error saying that the GatewayQuiz module is unable to load a subroutine from another WeBWorK module. But I'm having trouble seeing why that would be the case, because the exact same code is run (and the subroutine assignSetVersionToUser is executed) when the user starts the test. Thus, if the user has started the test successfully we know that the GatewayQuiz module was able to load the indicated subroutine.
So I'm at a bit of a loss to figure out why it fails when grading. Are you able to preview the test without any trouble? If you don't click "grade test" and instead return to the homework sets list there should be a link at the bottom of the list to let you resume the test. Does that work?
Thanks, and sorry we haven't gotten a more conclusive answer here,
Gavin
This is very odd. I don't think the permissions have anything to do with this. The error message is a Perl error, not a permissions error that is getting caught by WeBWorK.
The error message "'assignSetVersionToUser' is not exported by the WeBWorK::ContentGenerator::Instructor module" is a Perl error saying that the GatewayQuiz module is unable to load a subroutine from another WeBWorK module. But I'm having trouble seeing why that would be the case, because the exact same code is run (and the subroutine assignSetVersionToUser is executed) when the user starts the test. Thus, if the user has started the test successfully we know that the GatewayQuiz module was able to load the indicated subroutine.
So I'm at a bit of a loss to figure out why it fails when grading. Are you able to preview the test without any trouble? If you don't click "grade test" and instead return to the homework sets list there should be a link at the bottom of the list to let you resume the test. Does that work?
Thanks, and sorry we haven't gotten a more conclusive answer here,
Gavin
Gavin,
Thanks for the continuing ponderance. Here is an update. After creating the new quiz just for myself which did not get scored, I tried to create a new version but instead got the error message page. On a second try I got a blank page. I also got an error page when trying to look back at the version I had a already taken. I shall make another quiz and try some more things, including the preview that you mentioned, although I think that I did try this on a previous attempt and also got my error message. However, I am not so sure about that. A luta continua.
Bayne
Thanks for the continuing ponderance. Here is an update. After creating the new quiz just for myself which did not get scored, I tried to create a new version but instead got the error message page. On a second try I got a blank page. I also got an error page when trying to look back at the version I had a already taken. I shall make another quiz and try some more things, including the preview that you mentioned, although I think that I did try this on a previous attempt and also got my error message. However, I am not so sure about that. A luta continua.
Bayne
One more question: have you done anything to change your WeBWorK installation recently? I would also be tempted to restart apache on the server to see if it's some odd system caching error.
Gavin
Gavin
OK- continuing:
There have been no changes to the installation since the beginning of the fall semester. The initial gateway quiz (when things seemed to be working fine) was written only in late December. I did restart apache a couple of times with no apparent change in results.
Some additional notes:
I made a new short gateway quiz to try some more testing which I looked at with a dummy stucent account as well as my own. On one attempt, I was not able to get a preview, but able to score once. On other tries the results varied. Sometimes a blank page would appear and if this was a result of pressing the score button, no score was recorded. Some other times, the error message page would appear. On trying to look at an old quiz, there were similar results.
I shall continue to try new and different things.
Bayne
There have been no changes to the installation since the beginning of the fall semester. The initial gateway quiz (when things seemed to be working fine) was written only in late December. I did restart apache a couple of times with no apparent change in results.
Some additional notes:
I made a new short gateway quiz to try some more testing which I looked at with a dummy stucent account as well as my own. On one attempt, I was not able to get a preview, but able to score once. On other tries the results varied. Sometimes a blank page would appear and if this was a result of pressing the score button, no score was recorded. Some other times, the error message page would appear. On trying to look at an old quiz, there were similar results.
I shall continue to try new and different things.
Bayne
Have you checked your apache error log? There are sometimes errors that appear there that aren't shown on the screen.
We ran into a similar problem where sometimes you would get a blank screen after submitting. In our case it was a bug in a perl module which caused a segmentation fault in apache. In this case you would see reports of the seg fault in the apache error log.
The only other think I can think of is a version mismatch between the various webwork library files. For example, if you upgraded GatewayQuiz.pm, but not Instructor.pm, you could run into such errors, but in this case they would most likely not be intermittent.
We ran into a similar problem where sometimes you would get a blank screen after submitting. In our case it was a bug in a perl module which caused a segmentation fault in apache. In this case you would see reports of the seg fault in the apache error log.
The only other think I can think of is a version mismatch between the various webwork library files. For example, if you upgraded GatewayQuiz.pm, but not Instructor.pm, you could run into such errors, but in this case they would most likely not be intermittent.
Hi,
We have been seeing a bunch of blank pages lately when working in webwork, and I checked the apache2 error log. Entries look like this:
[Fri Jan 23 04:23:06 2009] [error] [client 71.142.138.59] File does not exist: /var/www/favicon.ico
[Fri Jan 23 07:46:09 2009] [error] [client 10.128.25.13] File does not exist: /var/www/favicon.ico
[Fri Jan 23 07:46:12 2009] [error] [client 10.128.25.13] File does not exist: /var/www/favicon.ico
[Fri Jan 23 07:46:22 2009] [notice] child pid 22510 exit signal Segmentation fault (11)
[Fri Jan 23 07:46:22 2009] [notice] child pid 22958 exit signal Segmentation fault (11)
[Fri Jan 23 07:46:37 2009] [notice] child pid 23320 exit signal Segmentation fault (11)
[Fri Jan 23 07:46:43 2009] [notice] child pid 20863 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:31 2009] [notice] child pid 20868 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:33 2009] [notice] child pid 20864 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:40 2009] [notice] child pid 22504 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:41 2009] [notice] child pid 20867 exit signal Segmentation fault (11)
I went further back, and these errors occur regularly as I look back through the logs. The two common errors in the logs have to do with "File does not exist" and "Segmentation fault (11)".
Any ideas what it is and how to how to fix it?
Danny, did you see similar log entries? How did you fix it?
Any help greatly appreciated - our semester begins on Monday.
We are running:
Webwork 2-4-patches - latest cvs
latest ubuntu (8.10) with all its latest packages:
libapache2-mod-perl2 v. 2.0.4-1
apache2 v. 2.2.9-7
perl v. 5.10
Thanks,
Lars.
We have been seeing a bunch of blank pages lately when working in webwork, and I checked the apache2 error log. Entries look like this:
[Fri Jan 23 04:23:06 2009] [error] [client 71.142.138.59] File does not exist: /var/www/favicon.ico
[Fri Jan 23 07:46:09 2009] [error] [client 10.128.25.13] File does not exist: /var/www/favicon.ico
[Fri Jan 23 07:46:12 2009] [error] [client 10.128.25.13] File does not exist: /var/www/favicon.ico
[Fri Jan 23 07:46:22 2009] [notice] child pid 22510 exit signal Segmentation fault (11)
[Fri Jan 23 07:46:22 2009] [notice] child pid 22958 exit signal Segmentation fault (11)
[Fri Jan 23 07:46:37 2009] [notice] child pid 23320 exit signal Segmentation fault (11)
[Fri Jan 23 07:46:43 2009] [notice] child pid 20863 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:31 2009] [notice] child pid 20868 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:33 2009] [notice] child pid 20864 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:40 2009] [notice] child pid 22504 exit signal Segmentation fault (11)
[Fri Jan 23 07:47:41 2009] [notice] child pid 20867 exit signal Segmentation fault (11)
I went further back, and these errors occur regularly as I look back through the logs. The two common errors in the logs have to do with "File does not exist" and "Segmentation fault (11)".
Any ideas what it is and how to how to fix it?
Danny, did you see similar log entries? How did you fix it?
Any help greatly appreciated - our semester begins on Monday.
We are running:
Webwork 2-4-patches - latest cvs
latest ubuntu (8.10) with all its latest packages:
libapache2-mod-perl2 v. 2.0.4-1
apache2 v. 2.2.9-7
perl v. 5.10
Thanks,
Lars.
Hi Lars,
Having been through both of these problems, I can share some insight.
"File does not exist: /var/www/favicon.ico" is not a real problem. Most new browsers when they connect to a website look for the favicon.ico file. This is the little icon that appears next to the url at the top of the browser window. It won't affect the behaviour of the system if it's not there. If you don't want to see these errors, you can create such a file and put it in the appropriate place (which according to your error looks like it should be /var/www/favicon.ico for your system). I'm sure you can find an appropriate icon online if your university doesn't have a standard one.
As for the segmentation faults, here is a link describing how to get more details regarding the crash:
http://bugs.mysql.com/bug.php?id=36810
In our case this led to some error messages regarding mysql_ping. Turns out that there is a problem with the perl DBD::mysql package versions 4.007 and 4.008. If the connection from the httpd process to the database is idle for a while, then it crashes the httpd process when it is next used . The bug is referenced here:
http://bugs.mysql.com/bug.php?id=36810
We tended to see these segmentation faults first thing in the morning, since apache tended to be idle overnight.
In our case reverting to DBD::mysql version 4.006 solved the problem, though according to the bug report the problem has been fixed in 4.010 (which wasn't available yet when we went through this).
Hope this helps. Of course this doesn't address Bayne's gateway errors, but will hopefully rid you of the blank screen problem.
Danny
Having been through both of these problems, I can share some insight.
"File does not exist: /var/www/favicon.ico" is not a real problem. Most new browsers when they connect to a website look for the favicon.ico file. This is the little icon that appears next to the url at the top of the browser window. It won't affect the behaviour of the system if it's not there. If you don't want to see these errors, you can create such a file and put it in the appropriate place (which according to your error looks like it should be /var/www/favicon.ico for your system). I'm sure you can find an appropriate icon online if your university doesn't have a standard one.
As for the segmentation faults, here is a link describing how to get more details regarding the crash:
http://bugs.mysql.com/bug.php?id=36810
In our case this led to some error messages regarding mysql_ping. Turns out that there is a problem with the perl DBD::mysql package versions 4.007 and 4.008. If the connection from the httpd process to the database is idle for a while, then it crashes the httpd process when it is next used . The bug is referenced here:
http://bugs.mysql.com/bug.php?id=36810
We tended to see these segmentation faults first thing in the morning, since apache tended to be idle overnight.
In our case reverting to DBD::mysql version 4.006 solved the problem, though according to the bug report the problem has been fixed in 4.010 (which wasn't available yet when we went through this).
Hope this helps. Of course this doesn't address Bayne's gateway errors, but will hopefully rid you of the blank screen problem.
Danny
If you want the WeBWorK favicon it is here:
also in
of the standard distribution. Lars will need to move it to the directory
for the webserver to serve it properly. In general it is placed in the default directory for the server.
http://cvs.webwork.rochester.edu/viewcvs.cgi/webwork2/htdocs/
also in
/webwork2/htdocs/favicon.ico of the standard distribution. Lars will need to move it to the directory
/var/www for the webserver to serve it properly. In general it is placed in the default directory for the server.
Hi,
Thanks for the suggestion Danny. We're running v. 4.007 of libdbd-mysql-perl. I couldn't find a deb package for v.4.010. I did find the source, but couldn't get it to compile. I also found a deb for v. 4.006 but it requires perl-api5.8.8, and we have perl-api5.10. I did force an install anyway, but got only blank pages after webwork login. So I ended up trying v. 4.008 which is available as a deb. I don't know if that's going to end the segmentation faults....
Thanks again for your help.
Lars.
Thanks for the suggestion Danny. We're running v. 4.007 of libdbd-mysql-perl. I couldn't find a deb package for v.4.010. I did find the source, but couldn't get it to compile. I also found a deb for v. 4.006 but it requires perl-api5.8.8, and we have perl-api5.10. I did force an install anyway, but got only blank pages after webwork login. So I ended up trying v. 4.008 which is available as a deb. I don't know if that's going to end the segmentation faults....
Thanks again for your help.
Lars.
it is unlikely that a 5.8.8 binary will work with perl 5.10 when loaded by mod_perl (though they may work when calling perl by hand). As I understand it, the binaries are linked against different versions of the libraries, and the mod_perl process will not load both. I have seen segmentation faults from this kind of thing. If you had to use CPAN to install any of the components used with WeBWorK and have update perl since then, you may need to recompile those older modules. The mysql module was one that gave me problems in this way. I recompiled it "by hand" (i.e., through the package from www.CPAN.org) and that cleared it up.
Davide
Davide
I also had to manually install the DBD::mysql package in order to get an earlier version. Install instructions are at http://cpansearch.perl.org/src/CAPTTOFU/DBD-mysql-4.010/INSTALL.html. If you check the section on manual install, there is a link to the source packages, where you can go get 4.006 or 4.010, along with instructions on installing them manually.
Hi Danny,
Since I had some trouble compiling the DBD::mysql v. 4.010 perl module from source, and our semester is starting Monday, I don't want to mess with the system. v. 4.008, as you also hinted, didn't fix the segmentation fault errors. So I included an "apache2ctl graceful" command in crontab to run once an hour. I haven't seen any segmentation faults since, but I probably need more time before I can be sure it works.
Are there any drawbacks to restart apache this way?
Lars.
Since I had some trouble compiling the DBD::mysql v. 4.010 perl module from source, and our semester is starting Monday, I don't want to mess with the system. v. 4.008, as you also hinted, didn't fix the segmentation fault errors. So I included an "apache2ctl graceful" command in crontab to run once an hour. I haven't seen any segmentation faults since, but I probably need more time before I can be sure it works.
Are there any drawbacks to restart apache this way?
Lars.
FYI:
After regular graceful restarts of apache the segmentation faults and blank pages have apparently gone away. Before, I had segmentation faults every day. I've had none since I scheduled graceful restart of apache every 3 hours.
Hopefully matters will stay this way until DBD::mysql v. 4.010 makes it into ubuntu.
Lars.
After regular graceful restarts of apache the segmentation faults and blank pages have apparently gone away. Before, I had segmentation faults every day. I've had none since I scheduled graceful restart of apache every 3 hours.
Hopefully matters will stay this way until DBD::mysql v. 4.010 makes it into ubuntu.
Lars.