Member Avatar for shaffatshah

hello everybody

void func1(){
// do something

//exit the function if some error occurs (like segmentation fault) but continue running the rest of the program
}

void func2(){

//do something

//exit the function if some error occurs (like segmentation fault) but continue running the rest of the program

}

int main(){
func1();
func1();
}

Ok for the above program, if any error (such as segmentation fault) occurs in func1, i want the function to end but continue running the rest of the program (i.e func2). I have used exit() and return 0, but not working. HELP!!!

  • 3 Contributors
  • 5 Replies
  • 192 Views
  • 12 Hours Discussion Span
  • Latest Post Latest Post by deceptikon

Dani AI

Generated

Segmentation faults are not ordinary returnable errors — they are delivered by the OS as SIGSEGV and, by default, terminate the whole process. That is why calling return or exit() inside the function (as in the original post) does not stop a segfault: the fault happens before normal control flow can reach those statements. For ordinary logical errors, ’s advice (return from the function) is correct; for memory faults a different approach is needed.

A robust and portable solution is to isolate the risky work in a separate process. If the child crashes, the parent can detect it (WIFSIGNALED/WTERMSIG) and continue. Basic pattern:

#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>

int run_isolated(void (*fn)(void)) {
    pid_t pid = fork();
    if (pid == -1) return -1;
    if (pid == 0) {
        fn();           /* run risky code in child */
        _exit(0);       /* avoid stdio flushing in parent */
    }
    int status;
    waitpid(pid, &status, 0);
    if (WIFSIGNALED(status)) return -2; /* child crashed */
    return 0;
}

Use a pipe or socketpair to return results from the child. In multithreaded programs, fork-only children should be used carefully — prefer spawning a helper process (fork+exec or posix_spawn) or a dedicated worker process started at program init.

The setjmp/siglongjmp approach mentioned by can work for small, controlled test harnesses: install a SIGSEGV handler that does siglongjmp() back to a saved sigsetjmp() point, and restore the old handler. This is dangerous in general: if the signal interrupted a non-async-signal-safe function or left shared state (locks, malloc internals, file streams) inconsistent, behavior is undefined and resource leaks or corruption can follow. If used at all, do so only inside narrowly audited regions, use sigaction with an alternate stack (SA_ONSTACK) if needed, and keep interaction with library routines minimal.

Recommendation: for real programs, prefer process isolation for untrusted or crash-prone code; use in-process signal recovery only for tightly controlled test code.

Recommended Answers

All 5 Replies

Member Avatar for deceptikon

Return from the function with a return statement and the program will continue to run from that point on. But if the program depends on results from the function that errored, you'll have problems later on.

Member Avatar for nezachem

Return from the function with a return statement and the program will continue to run from that point on

This is quite hard to do considering that "some error" can be a segfault. The OP goal is achieved via setjmp in the caller and longjmp from the signal handler.

Member Avatar for deceptikon

Oh, I didn't see that a seg fault was one of the potential errors. My bad.

Member Avatar for shaffatshah

Return from the function with a return statement and the program will continue to run from that point on. But if the program depends on results from the function that errored, you'll have problems later on.

Thanks a lot for your reply... but truely speaking i am a newbie in C, is it return 0 or return 1? the function is independent, its a test program, it executes and ends there, nothing is return, function starts with a void....

Member Avatar for deceptikon

function starts with a void....

Then you would use an empty return statement:

void foo()
{
    ...

    if (some error)
    {
        return;
    }

    ...
}
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.