Explanation of runtime errors

[tonowak]

Each year we get a lot of questions "what means that the program exited with code X?"

I would like to see an exact explanation why it returned with code X. For example:

The code had a runtime error. It returned with code X, which in general means that it dereferenced unused memory, for example because of out-of-box indexing of an array, (...).

I believe there should be a mapping in linux between returned code and unix name of signal.

It would be also helpful to explain that the runtime of code could differ between different environments and running under "test runs" can be helpful.

If the explanation is too long, we could hide it under a spoiler.

(it is a loose example)

Ideally, we would want it to be written and merged into SIO2 before this year's second stage of OI (13.02.2024). Would it be possible @twalen ?

[DietPawel]

tonowak, is signal list from signal(7) good enough?

[tonowak]

For the names of the signals -- yes -- but that also requires a Unix knowledge of what each signal means, so I still would want an explanation with most common examples.

[twalen]

From my experience it is not possible to uniquely link signal number to a type of error in a program.

[tonowak]

You mean that e.g. signal 11 can have reasons much different than the usual ones?

We could try to explain the most popular signal numbers. If it turns out that they sometimes have contradictory reasons, I would prefer to not show the signal number and to just explain what an runtime error is (and to redirect the user to test runs)

[DietPawel]

If there are no screen-space concerns we could probably make a list of potential causes of all the reasonable signals, but the text and the wording sounds like one of the challenges here.

[tonowak]

no screen-space concerns

We can hide the details in an extendable spoiler. For some people, just knowing what is the name of the signal is enough to understand what went wrong in their code, and for the other people, an extendable section with an explanation would be helpful.

[tonowak]

My current concern is that the current wording (e.g. only the number of the signal) is often confusing for contestants. In fact, even hiding this number might be better than having it in its current form. But I would like to avoid reverting functionality on the second stage, instead of the first stage of OI, and instead, I would greatly prefer to add the explanations.

[tonowak]

Is there a chance that this Issue is going to progress before this year's second OI stage?

[twalen]

I can review PR (if there will be one), but TAG classes resume on 2024-02-26. Right now there is exam session.

[metenn]

We added this internally for the 2nd stage of OI. I'll make a pull request soon.

[twalen]

@metenn Could you share the error codes mapping here?

[metenn]

Here's the PR. #334 It covers only common signals and the ones that have showed up in sio2: SIGKILL(9), SIGABRT(6), SIGSEGV(11), SIGBUS(7), SIGFPE(8), SIGSYS(31). But it also covers extra common errors like the relocation truncated to fit compilation error and a comprehensive explanation of the SE status.

For convenience, here are the mappings @twalen :

English

> Most common causes of the SIGABRT signal (signal 6): > - Out-of-bounds index access for the vector data structure > - Array allocation with an invalid size e.g. int tab[-1]; > - Bad use of C++ standard library functions, e.g. sort() over an invalid range > - A failed assertion when using assert - commonly used by the C++ Standard Library > - Other illegal memory operations. > The SIGBUS signal (signal 7) can mean a general memory violation, and can > be caused by trying to access an invalid memory address. > Most common causes of the SIGFPE signal (signal 8): > - Overflows/underflows for floating-point numbers > - Division by zero, either with floating-point numbers and integers > - Other illegal arithmetic operations, e.g. square-root of negative numbers. > rations. > Most common sources for the SIGKILL signal (signal 9): > - Your global variable exceeds the memory limit > (The difference compared to MLE is that the program exits before it can even "fully start") > - Other unexpected operations causing the program to get terminated preemptively. > Most common causes of the SIGSEGV signal (signal 11): > - Out-of-bounds array accesses > - De-referencing an invalid pointer (an empty "null-pointer" or a pointer to memory which has already been freed) > - Other memory violation errors > Most common causes of the SIGSYS signal (signal 31): > - Using a system call (syscall) that's not allowed by this task/contest. > - Using an invalid/non-existent system call.

Polish

> Najczęstsze przyczyny sygnału SIGABRT (sygnał 6): > - Wykroczenie poza zakres vector'a > - Alokacja tablicy z błędnym rozmiarem np. int tab[-1]; > - Błędne wykorzystanie funkcji z biblioteki standardowej C++, np. sort() po złym zakresie > - Nieudane sprawdzenie niezmiennika podczas korzystania z assert - często używane przez bibliotekę standardową C++. Może to oznaczać wyjście poza zakres kontenera z biblioteki standardowej > - Inne błędy nielegalnych operacji na pamięci. > Sygnał SIGBUS (sygnał 7) oznacza ogólną awarię pamięci, może być spowodowany próbą dostępu do nieprawidłowego adresu w pamięci. > Najczęstsze przyczyny sygnału SIGFPE (sygnał 8): > - Przekroczenie zakresu górnego/dolnego dla typu zmiennoprzecinkowego > - Dzielenie liczby całkowitej lub zmiennoprzecinkowej przez 0 > - Inne niedopuszczone operacje arytmetyczne, np. pierwiastek na liczbach ujemnych. > Najczęstsze przyczyny sygnału SIGKILL (sygnał 9): > - Zmienna globalna przekracza limit pamięci > (Różnica z MLE jest taka, że program przekracza pamięć zanim się zdąży "w pełni uruchomić") > - Inne nieoczekiwane operacje, które prowadzą do przedwczesnego zakończenia działania programu. > Najczęstsze przyczyny sygnału SIGSEGV (sygnał 11): > - Wykroczenie poza zakres rozmiaru tablicy. > - Odwołanie się do danych niepoprawnego wskaźnika (pustego wskaźnika \"null-pointer\" lub wskaźnika po zwolnieniu danych). > - Ogólny błąd naruszenia ochrony pamięci. > Najczęstsze przyczyny sygnału SIGSYS (sygnał 31): > - Użycie wywołania systemowego (system call) niedozwolonego podczas zawodów > - Użycie niewłaściwego lub nieistniejącego wywołania systemowego.