Execution environment
Host
The solver will be executed on a virtual machine that simulates a
GNU/Linux host of architecture x86, 32 bit, single-processor.
Available software
On the virtual machine are installed:
-
A standard POSIX environment. In particular a POSIX-compatible
shell, which may be invoked by /bin/sh, will be
available, as well as a GNU Bourne-Again SHell (invoked
as /bin/bash).
-
A Java Runtime Environment (JRE) 6; the Java application
launcher can be invoked as /usr/bin/java.
-
A Python 2.5 environment; the main Python interpreter can be invoked as
/usr/bin/python.
No other libraries, for any programming language, can a priori be assumed
to be available in the chroot environment. That means:
-
Solvers prepared using compilers supporting compilation to ELF
must be submitted as statically linked ELF binaries. No
assumptions can be made on available shared libraries
(.so) in the chroot environment.
-
Solvers written in some (supported) interpreted language must use
the usual shebang lines (#!/path/to/interpreter) to
invoke their interpreter.
-
Solvers written in Java must be wrapped by shell scripts invoking
the Java application launcher as needed.
-
Solvers needing other kind of support in the chroot must make
specific arrangements with the competition organizers
before the final submission.
Resource limitation
The solver execution will be additionally constrained by the following
limits (as implemented by ulimit):
- Maximum execution time: 5 minutes
- Maximum memory (RAM): 1 GB
- Maximum file system space: 1 GB (including the solver itself)
The execution time is cpu time, measured in the same way
as ulimit -t. About 20 seconds before the timeout, the
signal SIGUSR1 will be sent to the solver process.
It is the responsibility of the solver to catch that signal, produce
an output, and terminate normally.
Solver invocation
- The solver will be executed from within the solver directory.
- Each problem of the competition will be run in a fresh copy of
the solver directory.
- The solver will be called with 2 command line
arguments: cudfin and cudfout, in this
order. Both arguments are absolute file systems paths.
<ol>
<li>
<kbd>cudfin</kbd> points to a complete CUDF 2.0 document,
describing an upgrade scenario. The CUDF document will be
encoded as ASCII plain text, not compressed. The CUDF 2.0
format is <a href=../../reports/tr3.pdf>specified here</a>.
<p>
According to the specifications, the document will consist
of an optional preamble stanza, followed by several package
stanzas, and ended by a request stanza.
<li>
<kbd>cudfout</kbd> points to a non-existent file that
should be created by the solver to store its result.
</ol>
Solver output
-
The solver's standard output may be used to emit informative
messages about what the solver is doing.
-
If the solver is able to find a solution, then it must:
- write to cudfout the solution encoded in CUDF
syntax as described in Appendix B of the
CUDF 2.0 specification;
- exit with an exit code of 0.
-
If the solver is unable to find a solution, then it must:
- write to cudfout the string "FAIL" (without
quotes), possibly followed by an explanation in subsequent lines
(lines are separated by newline characters, ASCII 0x0A);
- exit with an exit code of 0.
- All exit codes other than 0 will be considered as indications
of unexpected and exceptional failures not related to the inability
to find a solution.