PC2 Version 8.2 FAQ and Troubleshooting Guide
This page lists some of the common problems which users have reported encountering while trying to set up and use PC2. It explains some reasons why the problems might occur, and provides suggestions for trying to eliminate them.
Click here to see the PC2 Version 7.6 FAQ
Field Names:
Variables: (these are filled in by pc2 during run-time)
Example input file name: hello.java
Display Name: GNU C (gcc)
Compile Cmd Line: gcc -lm -o {:basename} {:mainfile}
Executable Filename: {:basename}
Program Execution Command Line: {:basename}
Display Name: GNU C++
Compile Cmd Line: g++ -o {:basename} {:mainfile}
Executable Filename: {:basename}
Program Execution Command Line: {:basename}
Display Name: Java
Compile Cmd Line: javac {:mainfile}
Executable Filename: {:basename}.class
Program Execution Command Line: java {:basename}
Display Name: Kylix Delphi
Compile Cmd Line: dcc {:mainfile}
Executable Filename: {:basename}
Program Execution Command Line: {:basename}
Display Name: Kylix C++
Compile Cmd Line: bc++ -A {:mainfile}
Executable Filename: {:basename}
Program Execution Command Line: {:basename}
Display Name: Turbo Pascal (DOS)
Compile Cmd Line: tpc {:mainfile}
Executable Filename: {:basename}.exe
Program Execution Command Line: {:basename}.exe
We have noticed that under certain conditions the Java virtual machine
which is acting as the interface between PC2 and the host
OS does not accurately handle the connection between PC2 and
the external processes being used to execute the team program. In fact,
this can also happen when executing the compiler command used to produce
the team's executable program.
The problem seems to occur more frequently under Unix/Linux simply
because those OS's are faster in the way they handle spawning and
handling of the I/O channels for processes.
We are currently investigating this issue and seeking a permanent
solution. Meanwhile, we have discovered that a workaround appears
to be simply slowing the external processes down under Unix/Linux so
that the JVM has time to keep up with the external OS process management
operations.
For example, we have successfully eliminated this problem
in a large Regional Contest by defining each "compiler call" (language)
in PC2 so that instead of directly invoking the compiler,
it invokes a short script (which we call "slowdown"), whose contents
are simply:
We do a similar thing to invoke the executable program:
What this does is simply execute the "slowdown" script, passing it the
rest of the compile (or execute) command as arguments; the script in
turn runs the "nice" command which again in turn runs the command
(arguments), but at a low process priority.
Note that the "slowdown" script must appear somewhere in the "path";
we typically put it in the PC2 installation directory.
We do note that one undesirable side effect of this two-level process
structure (running a script to run the actual program) is that if
the actual program hangs for any reason -- for example, a team submits
a program with an infinite loop -- and then the Judge uses the
"Terminate" button on the Execution Timer, what gets terminated is
the external script process, not the actual team program program process
running "niced". This means that the Judge will need to use "ps" and
"kill" ("TaskManager" for Windows types) to remove the looping
process. We are working on a fix for this side effect.
#!/bin/sh
nice -19 $*
We then define the compiler execution command (using the PC2
Languages tab in the Administrator) to be (for example for gcc):
slowdown gcc -o {:basename} {:mainfile}
slowdown {:basename}
We have seen this happen when a Linux machine running the PC2
Server has not been properly configured for a network environment.
Specifically, Linux machines typically start up configured to report
their "machine name" as "localhost". PC2 queries the OS to
obtain the machine name, and then maps this name to a corresponding IP
address. The machine name "localhost" maps to the "loopback" IP
address 127.0.0.1. This ends up being the IP address which the
PC2 Server broadcasts to the Clients as the address
they should use for communication back to the Server -- which means
the Clients will be unable to contact the Server because they will
use their own local loopback channel.
To check whether your Linux machine running the PC2 Server
has this problem, type the command "hostname" (or "/bin/hostname")
at a command prompt. If this returns "localhost", your OS is not
properly configured for network operations.
One way to fix this problem on most machines is to edit the file
/etc/sysconfig/network and change the HOSTNAME entry to a host name
which resolves to a non-local IP address, and then reboot the machine.
Another approach is to use the "hostname" command, run as root,
to set the hostname to either a specific non-local IP address or
to a hostname which resolves to a non-local IP address.
One user with this problem wound up changing the hostname
before starting PC2, via a command line like:
which is basically getting the address from the eth0 interface
and setting the hostname to that value.
In any case, be sure to coordinate such actions with your local network
administrator.
hostname $(ifconfig eth0 | grep inet | sed 's/.*r:\| B.*//g')
or (depending on your shell)
hostname `ifconfig eth0 | grep inet | sed 's/.*r:\| B.*//g'`
However, the Scoreboard module ALSO automatically
generates a collection of HTML files showing contest
standings and submission data in several different formats. These
HTML files are updated and placed in a directory name "html"
under the $PC2HOME directory (PC2
installation directory) each time there is a change in the contest
standings state (roughly, each time a submission is judged).
This updating is done automatically, on the fly as the state changes.
There are currently FIVE different HTML files generated:
You can therefore get to the "text data" from the scoreboard by picking it
out of the HTML files, if that's what you want. However, since the
generated files are full valid HTML, you can simply use them as-is.
For example, when we run a contest under PC2 (as if there was
some other way...) we never run more than ONE Scoreboard module for
the entire contest (even if it is a multi-site contest spread over
multiple continents). Once we have one Scoreboard module running,
we build an external "master" HMTL file containing references to the
PC2 directory HTML files (for example, we insert the various
PC2
HTML files into frames in the master page,
along with things like a header frame
showing the contest title and graphics and so forth). We then write
a script (batch file) to copy the master page to some publicly published
location at regular intervals (e.g. once per minute).
We then tell people who want to see the "scoreboard" (for example,
Teams, Judges, Spectators) to simply point their favorite browser to the
"public" location.
The PC2 Scoreboard will update the
PC2 HTML files whenever the standings change; the script
will copy the updated HTML files to the public location at the frequency
we specify.
This approach also makes it easy to "freeze" the (public) scoreboard
at some point near the end of the contest, if that's what is desired:
simply kill the script which is doing the copying (but not the
PC2 Scoreboard module itself). The internal
scoreboard will continue to update, while the public HTML scoreboard
will "freeze" at the last displayed form.
Note also that if the reverse happens -- e.g. a Client gets killed or
shut down improperly without executing a "log out" operation --
the system will think the Client is still
"logged in" and will not allow the Client to reconnect when it starts
back up -- it considers it a "duplicate login". To fix this, simply
use the "Force Logout" function in the Admin to make the system drop
the login connection to the dead Client, then have the Client log back
in normally. The same is true if a Server dies in a multi-site contest;
before the Server can "reconnect" to the system, it must be "forced off"
by the Administrator. (We're working on improving this aspect of the
system...)
File lines starting
with ! or # in the first column are ignored. Each non-comment line has FOUR
fields, separated by a pipe (|). The fields are:
Note: a blank "active" field is considered false
(so the example above will cause
team 2 to become inactive). True and false are not case sensitive.
Account_number
Display_name
Active (either "true" or "false")
Password
For example:
1|Number 1|true|pass1
2|Team Number 2||pass33
Note: it is important to create PC2 Accounts BEFORE importing ICPC data.
The import function assigns imported account information to PC2 accounts in
the order in which the accounts are encountered in the import data files.
(Creating a .zip file for support)
"java pc2.ZipPC2"
; this will create a .zip file of
the system. (If the problem relates to multiple modules on multiple
machines, please send a zip for each module).
pc2@ecs.csus.edu
Revised: Sat Feb 22 00:40:43 PST 2003