SIGABORT reported as signal 11

[veluca93]

While testing this solution

#include <cassert>
int main(){
    assert(false);
}

the sandbox reports "Execution killed with signal 11.", which is not the case.

[bblackham]

This is a known bug (feature?) of the sandbox. The only two signals that may exit the process are 11 and possibly SIGFPE (IIRC).

Is this a major issue? Or could it remain documented behaviour?

The cause for this is that the sandboxed process runs inside a PID namespace with PID 1. PID 1 traditionally cannot receive any signals. The code for abort() sends a SIGABRT to the process (which is ignored because it is PID 1), and then abort() executes an undefined instruction which causes the signal 11.

[veluca93]

Well, the question reduces to "Do we want the contestants to know what signal killed their program, or not?"

If we do, then it's a major issue, otherwise we shoud change that "Execution killed with signal 11" with a "Execution killed with some signal" or something like that...

[bblackham]

I've no strong opinion here. I'm happy for others to weigh in.

It's been suggested in the past giving more than "program crashed" could allow competitors to easily reverse engineer the test data.

[veluca93]

Yes, that was because mo-box let solutions be "killed" with an arbitrary 32bit integer (#58, by the way i think this should be closed now)
Giving signal numbers in their "right" range (1-64 or something like that) should not be enough to get informations about testcases. We also could filter signals so that they only are signal 6/9/11/other signal or something like that..

[veluca93]

After thinking a bit, i think this should be the best compromise between giving useful information to contestants and making most cheating attempts unfeasible:

• 8, SIGFPE -> "floating point exception"
• 9, SIGKILL -> "out of memory"
• 11, SIGSEGV -> "segmentation fault"
• anything else -> "runtime error"

We could also treat differently SIGABORT, but I don't see any reason for a signal other than FPE, KILL, SEGV or ABORT to ever appear in a contest environement, so we could merge them.
Mapping SIGKILL to an out-of-memory error is done because, with the old sandbox, trying to allocate too much static memory caused the process to be killed before even starting, with signal 9. I'm not sure if this will happen in the new sandbox too, but I don't see any other reason for a solution to be killed with a SIGKILL.

[giomasce]

Il 06/04/2013 00:03, veluca93 ha scritto:

After thinking a bit, i think this should be the best compromise between giving useful information to contestants and making most cheating attempts unfeasible:

• 8, SIGFPE -> "floating point exception"
• 9, SIGKILL -> "out of memory"
• 11, SIGSEGV -> "segmentation fault"
• anything else -> "runtime error"
  We could also treat differently SIGABORT, but I don't see any reason for a signal other than FPE, KILL, SEGV or ABORT to ever appear in a contest environement, so we could merge them.
  Mapping SIGKILL to an out-of-memory error is done because, with the old sandbox, trying to allocate too much static memory caused the process to be killed before even starting, with signal 9. I'm not sure if this will happen in the new sandbox too, but I don't see any other reason for a solution to be killed with a SIGKILL.

Personally I prefer avoid interpreting: it is reasonable to give a
subset of all signals that we allow the contestants to see ("your
program died with signal x") and write "your program died with another
signal" in all other cases. I consider it contestant's duty to know
signals' meaning (more or less as I consider contestant's duty to know
why a wrong C program doesn't compile).

Giovanni.

Giovanni Mascellani [email protected]
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: [email protected] / [email protected]

[lw]

Moved to cms-dev/isolate#9.