История изменений

SEH Equivalent in Linux or How do I handle OS Signals (like SIGSERV) and yet keep continuing

As you said, you could catch SIGSEGV via signal() or sigaction().
Continuing is not really advisable, as this would be undefined behaviour, i.e. 
your memory might be corrupted, which might let other test cases fail as well (or even terminate your whole process prematurely).
Would it be possible to run the test cases one by one as a sub process?
This way, you could check the exit status and will detect if it terminated cleanly, with an error or due to a signal.

Running the test cases in a separate thread will have the same 
problem: you do not have memory protection between your test 
cases and the code driving the test cases.

The suggested approach would be:
fork() to create a child process.
In the child process, you execve() your test case.

This could be the same binary with different arguments to select a certain test case).

In the parent process, you call waitpid() to wait for the termination of the test case. You received the pid from the 
fork() call in the parent process.

Evaluate the sub-process status with the WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG macros.

If you need timeouts for your test cases, you can also install a handler for SIGCHLD.

If the timeout elapses first, kill() the child process.
Be aware that you may only call certain functions from signal handlers.

Just a further note: execve() is not really required.
You can just proceed and call your specified testcase directly.

SEH Equivalent in Linux or How do I handle OS Signals (like SIGSERV) and yet keep continuing

As you said, you could catch SIGSEGV via signal() or sigaction().
Continuing is not really advisable, as this would be undefined behaviour, i.e. 
your memory might be corrupted, which might let other test cases fail as well (or even terminate your whole process prematurely).
Would it be possible to run the test cases one by one as a sub process?
This way, you could check the exit status and will detect if it terminated cleanly, with an error or due to a signal.

Running the test cases in a separate thread will have the same 
problem: you do not have memory protection between your test 
cases and the code driving the test cases.

The suggested approach would be:
fork() to create a child process.
In the child process, you execve() your test case.

This could be the same binary with different arguments to select a certain test case).

In the parent process, you call waitpid() to wait for the termination of the test case. You received the pid from the 
fork() call in the parent process.

Evaluate the sub-process status with the WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG macros.

If you need timeouts for your test cases, you can also install a handler for SIGCHLD.

If the timeout elapses first, kill() the child process.
Be aware that you may only call certain functions from signal handlers.

Just a further note: execve() is not really required.
You can just proceed and call your specified testcase directly.

SEH Equivalent in Linux or How do I handle OS Signals (like SIGSERV) and yet keep continuing

As you said, you could catch SIGSEGV via signal() or sigaction().
Continuing is not really advisable, as this would be undefined behaviour, i.e. 
your memory might be corrupted, which might let other test cases fail as well (or even terminate your whole process prematurely).
Would it be possible to run the test cases one by one as a sub process?
This way, you could check the exit status and will detect if it terminated cleanly, with an error or due to a signal.

Running the test cases in a separate thread will have the same 
problem: you do not have memory protection between your test 
cases and the code driving the test cases.

The suggested approach would be:
fork() to create a child process.
In the child process, you execve() your test case.

This could be the same binary with different arguments to select a certain test case).

In the parent process, you call waitpid() to wait for the termination of the test case. You received the pid from the 
fork() call in the parent process.

Evaluate the sub-process status with the WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG macros.

If you need timeouts for your test cases, you can also install a handler for SIGCHLD.

If the timeout elapses first, kill() the child process.
Be aware that you may only call certain functions from signal handlers.

Just a further note: execve() is not really required. You can just proceed and call your specified testcase directly.

SEH Equivalent in Linux or How do I handle OS Signals (like SIGSERV) and yet keep continuing

As you said, you could catch SIGSEGV via signal() or sigaction().
Continuing is not really advisable, as this would be undefined behaviour, i.e. 
your memory might be corrupted, which might let other test cases fail as well (or even terminate your whole process prematurely).
Would it be possible to run the test cases one by one as a sub process?
This way, you could check the exit status and will detect if it terminated cleanly, with an error or due to a signal.

Running the test cases in a separate thread will have the same 
problem: you do not have memory protection between your test 
cases and the code driving the test cases.

The suggested approach would be:
fork() to create a child process.
In the child process, you execve() your test case.

 This could be the same binary with different arguments to select a certain test case).

In the parent process, you call waitpid() to wait for the termination of the test case. You received the pid from the 
fork() call in the parent process.

Evaluate the sub-process status with the WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG macros.

If you need timeouts for your test cases, you can also install a handler for SIGCHLD.

If the timeout elapses first, kill() the child process.
Be aware that you may only call certain functions from signal handlers.

Just a further note: execve() is not really required. You can just proceed and call your specified testcase directly.

SEH Equivalent in Linux or How do I handle OS Signals (like SIGSERV) and yet keep continuing
As you said, you could catch SIGSEGV via signal() or sigaction().
Continuing is not really advisable, as this would be undefined behaviour, i.e. your memory might be corrupted, which might let other test cases fail as well (or even terminate your whole process prematurely).
Would it be possible to run the test cases one by one as a sub process? This way, you could check the exit status and will detect if it terminated cleanly, with an error or due to a signal.

Running the test cases in a separate thread will have the same 
problem: you do not have memory protection between your test 
cases and the code driving the test cases.

The suggested approach would be:
fork() to create a child process.
In the child process, you execve() your test case.

 This could be the same binary with different arguments to select a certain test case).

In the parent process, you call waitpid() to wait for the termination of the test case. You received the pid from the 
fork() call in the parent process.

Evaluate the sub-process status with the WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG macros.

If you need timeouts for your test cases, you can also install a handler for SIGCHLD.

If the timeout elapses first, kill() the child process.
Be aware that you may only call certain functions from signal handlers.

Just a further note: execve() is not really required. You can just proceed and call your specified testcase directly.